Marcus Brinkmann <[EMAIL PROTECTED]> writes: > The question is, how do I proceed? I tried running make through gdb, which > did not show anything useful. I only can use gdb like this: set args, run, > wait for breakage, interrupt, "bt", which showed only a single line in > libc02, where it stuck. I can probably find more info by using a libc0.2 > with development info. How do I use that instead of the normal libraries?
The first thing you need is fully ensymboled binaries. I am still upset that the Debian packages don't have symbols, and I really really want people to rethink this bug. But given that, you just have to have ensymboled binaries. Then I would run things in a sub hurd to examine the bug. In that way your machine will not blow up, because what ever thing causes the bug will happen to the sub hurd, which will crash and burn, but not affect the top level Hurd. In that way you can see where things are stuck. In such an environment it's usually pretty easy to find out what's blocked or crashing, and then to track things back to find out which call caused the problem. Then you start your subhurd again, attach a debugger to the task that fails, and elicit the bug and watch it happen, and do debugging as you would in any other kind of program. > How can I proceed in localization of the bug? How do I found out which RPC > blocks, or in which routine I have to search? Suppose you know that it's the filesystem that crashes. In that case, attach a debugger to it and wait for the crash. Then you can use the GDB "thread list" command to see all the active threads, and look at their stacks. It's generally totally obvious which thread generated the fault. > More info: After interrupting, I can't start any more programs, although the > shell still works. If I understood correctly, that's a problem with the exec > server... Or the filesystem, more commonly. Thomas
