[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Where's Grub?



Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> 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


Reply to: