Re: investigate a multi-threaded core

[Jim Blandy <jimb@codesourcery.com>]

"haoran woo" <haoran.woo at gmail.com> writes:
> I am investigating a multi-threaded core, from info threads, I can see
> two threads (thread 1 and thread 6) were doing something when the
> process cored, while other thread
> is sleeping or waiting for a signal.  I have two questions:
>
> 1. how to know which thread caused the crash?
> when bring up the core by "gdb prog core", and do bt, the stack trace
> is for thread 1, but from looking at the code, can not find any clue;
> however, thread 6 is a little bit more suspcious.
> but since gdb by default brings up thread 1, I am not sure whether I
> should focus on thread 6 or thread 1.

If I'm reading correctly, GDB just selects the first thread it finds
listed in the core file.  I don't know of anything that indicates
which thread took the signal, or the status of each thread.  If
something looks suspicious in thread 6, I'd say that's where to
concentrate.

> 2. this is a stripped library, how to find the args passed to the
> function call? I am using info frame, but the address give me
> anything, since this is a C++ object, and I expect to see the first
> arguments should have some vtable (the class has virtual functions).

Those are interesting stack pointer values.  Is this i386 Linux?

The strategy for finding arguments without symbols depends on knowing
your ABI's function calling conventions well.  I'd try to look for
some value I recognized, like the saved PC, and then figure out how
the stack is laid out from there.

I don't think we can really help you with your debugging.  This
mailing list is for discussing GDB itself.  If you have any questions
about GDB itself, we'll do our best to answer them.