On Mon, Feb 18, 2008 at 06:17:15PM +0100, Martin Michlmayr wrote: > * Martin Michlmayr <[EMAIL PROTECTED]> [2008-01-28 22:37]: > > > Hmm, argh. As you note, the results are not terribly illuminating. If I > > > could take a little more of your time, is it possible that you could run > > > src/mandb --debug under valgrind? Unfortunately there is quite a lot of > > > memory management being done at the point indicated by the debug dump, > > > and gdb isn't being helpful about providing the stack frame; I've tried > > > to figure it out from the addresses shown but have so far failed. With > > > any luck, valgrind should clear this up. > > This is an ARM box, for which valgrind isn't available. Anything else > > I could try? > > I just transfered /var/cache/man and /usr/share/man to another machine > in hope I can reproduce it there but I cannot. Seems I can only > reproduce it on this particular machine. Any idea what info to send > you?
My main problem here is figuring out exactly where it's crashing, since the stack appears to be corrupt. Perhaps you could build a debug version (as before) and run 'sudo gdb --args src/mandb --debug', then: break dbstore condition 1 !strcmp(base, "tset") run ... and then step through (using 'n') until it crashes? At that point I'd like to see a transcript of the gdb session. If you can, please try this procedure with man-db 2.5.3-1 in experimental (after checking whether it suffers from this problem). I fixed quite a few possible crashes in 2.5.3, and at any rate it's always easier to work with gdb transcripts that are closer to current code. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
