Re: aborted thread backtrace stops at sighandler call

[Jason Molenda <jmolenda@apple.com>]

On Jun 24, 2005, at 8:11 AM, Louis LeBlanc wrote:

> 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?)
>
> But pstack shows this:
> -----------------  lwp# 3 / thread# 3  --------------------
>  fea1f82c _lwp_kill (6, 0, fe7765b8, fe776630, 0, 1) + 8
>  fe9b6cd8 abort    (df708, 0, 0, 0, 0, 0) + 100
>  0003c724 XPCSigCheck (b, fe776ad0, fe776818, 0, 0, 0) + 2c0
>  ff365b0c __sighndlr (b, fe776ad0, fe776818, 3c464, 0, 0) + c
>  ff35f804 call_user_handler (b, fe776ad0, fe776818, 0, 0, 0) + 234
>  ff35f9b4 sigacthandler (b, fe776ad0, fe776818, 7efefeff, 81010100,  
> 0) + 64
>  --- called from signal handler with signal 11 (SIGSEGV) ---


I don't have anything better than Daniel to suggest, but the problem  
here is specifically that backtracing through a signal handler is a  
special case -- it's the most fragile part of any backtracer in gdb  
-- and that's where your back trace is failing.

J