This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: aborted thread backtrace stops at sighandler call
- From: Daniel Jacobowitz <drow at false dot org>
- To: gdb at sources dot redhat dot com
- Date: Fri, 24 Jun 2005 14:29:17 -0400
- Subject: Re: aborted thread backtrace stops at sighandler call
- References: <20050624151129.GH66895@keyslapper.net>
On Fri, Jun 24, 2005 at 11:11:29AM -0400, Louis LeBlanc wrote:
> Well, often these were bus errors and gdb just couldn't nail things
> down for me. Finally, I decided to catch these signals (SIGBUS,
> SIGSEGV) and collect what info I could before calling abort() - which
> preserves the stack pretty well according to pstack. When a problem
> arises, I can look at the pstack output and see quite clearly that the
> problem is this screwy network glitch I've never been able to track
> down. Problem is when it's something else, gdb doesn't seem to be
> able to see the preserved stack.
>
> Anyone have any idea how to get this?
>
> This is the backtrace for the aborted thread:
> (gdb) bt
> #0 0xfea1f82c in __tbl_2_huge_digits () from /usr/lib/libc.so.1
> #1 0xfe9d0a24 in sysconf () from /usr/lib/libc.so.1
> #2 0xfe9b6ce0 in ascftime () from /usr/lib/libc.so.1
> #3 0x0003c72c in XPCSigCheck (Sig=11, Info=0xfe776ad0, Context=0xfe776818) at xpcsig.c:347
> #4 0xff365b14 in ?? ()
> #5 0xff365b18 in ?? ()
> Previous frame identical to this frame (corrupt stack?)
What this amounts to is a bug in GDB's signal frame unwinder for
Solaris; I'm afraid I can't offer you any more help than that, since I
don't generally develop or test on Solaris.
--
Daniel Jacobowitz
CodeSourcery, LLC