Re: aborted thread backtrace stops at sighandler call

Daniel Jacobowitz
2005-06-24T18:29:23Z

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