SV: Which thread caused dump?

Steffen Schumacher
2006-08-29T13:23:20Z

Ok but it doesn't show me much. Hmm..

My stack must have been overwritten:
> (gdb) bt
> #0 0x2834f46b in pthread_testcancel () from /usr/lib/libpthread.so.2
> #1 0x28347e3c in pthread_mutexattr_init () from
> /usr/lib/libpthread.so.2
> #2 0x284fa450 in ?? ()
> (gdb)

#2 seems to start out of the blue..
How do you go about chasing a bug like this?

/Steffen

-----Oprindelig meddelelse-----
Fra: Daniel Jacobowitz [mailto:drow@false.org]
Sendt: 29. august 2006 14:39
Til: Steffen Schumacher
Cc: gdb@sourceware.org
Emne: Re: Which thread caused dump?

On Tue, Aug 29, 2006 at 12:42:40PM +0200, Steffen Schumacher wrote:
> Hi!
>
> I have a multithreaded program which coredumps after ~20 hours of
> running.
> Is it possible to see which thread caused the crash?
> Usually I use thr x and bt for seeing if some exception was thrown,
but
> I have a case where no thread is throwing any exceptions.
>
> I've enclosed output from the actual core dump.. any other cmd's I
> should know of?
> Any help on discovering why it is crashing would be greatly
> appreciated..

Generally the first thread that comes up is the one that crashed.

> Program terminated with signal 11, Segmentation fault.

> * 10 LWP 100080 0x2834f4ab in pthread_testcancel () from
> /usr/lib/libpthread.so.2

> (gdb) thr 10
> [Switching to thread 10 (LWP 100080)]#0 0x2834f46b in
> pthread_testcancel () from /usr/lib/libpthread.so.2
> (gdb) bt
> #0 0x2834f46b in pthread_testcancel () from /usr/lib/libpthread.so.2
> #1 0x28347e3c in pthread_mutexattr_init () from
> /usr/lib/libpthread.so.2
> #2 0x284fa450 in ?? ()
> (gdb)
>

So probably right there.