Re: aborted thread backtrace stops at sighandler call

[Daniel Jacobowitz <drow@false.org>]

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