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: Jason Molenda <jmolenda at apple dot com>
- To: GDB question <gdb at sources dot redhat dot com>
- Date: Fri, 24 Jun 2005 11:52:37 -0700
- Subject: Re: aborted thread backtrace stops at sighandler call
- References: <20050624151129.GH66895@keyslapper.net>
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