This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
SV: Which thread caused dump?
- From: "Steffen Schumacher" <STEFF at tdc dot dk>
- To: <gdb at sourceware dot org>
- Date: Tue, 29 Aug 2006 15:23:11 +0200
- Subject: SV: Which thread caused dump?
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.
--
Daniel Jacobowitz
CodeSourcery