investigate a multi-threaded core

investigate a multi-threaded core

[haoran woo]

Hi,
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.

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).
e.g,
 called by frame at 0xffffcb84
 Arglist at 0xffffcb38, args:
 Locals at 0xffffcb38, Previous frame's sp is 0xffffcb40
 Saved registers:
  ebx at 0xffffcb04, ebp at 0xffffcb38, esi at 0xffffcb0c, edi at
0xffffcb08, eip at 0xffffcb3c

(gdb) x 0xffffcb38
0xffffcb38:     0xffffcb7c
(gdb) x 0xffffcb7c
0xffffcb7c:     0xffffcb98
(gdb)

Thanks for your help.

-Haoran

Re: investigate a multi-threaded core

[Jim Blandy]

"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.