Red Hat Bugzilla – Bug 117972
signal backtrace broken
Last modified: 2007-11-30 17:07:00 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 Description of problem: Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.set a breakpoint in a signal handler 2.run to the signal handler 3.do a backtrace Actual Results: (gdb) break handler Breakpoint 1 at 0x10000470: file /tmp/segv.c, line 9. (gdb) run Starting program: /tmp/segv.32 Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) signal SIGSEGV Continuing with signal SIGSEGV. Breakpoint 1, handler (sig=11, info=0xffffe390, context=0x100004f4) at /tmp/segv.c:9 warning: Source file is more recent than executable. 9 exit (0); (gdb) bt #0 handler (sig=11, info=0xffffe390, context=0x100004f4) at /tmp/segv.c:9 #1 <signal handler called> Cannot access memory at address 0xffffe430 (gdb) Additional info: #include <stdio.h> #include <signal.h> #include <ucontext.h> #ifdef SA_SIGINFO static void handler (int sig, siginfo_t *info, ucontext_t *context) { exit (0); } #else static void handler (int sig, int code, struct sigcontext *scp) { exit (0); } #endif static void segv (void (*f) (void)) { f(); } main () { static struct sigaction action; #ifdef SA_SIGINFO action.sa_sigaction = handler; action.sa_flags |= SA_SIGINFO; #else action.sa_handler = handler; #endif sigaction (SIGSEGV, &action, NULL); segv (NULL); }
*** Bug 85247 has been marked as a duplicate of this bug. ***
*** Bug 85309 has been marked as a duplicate of this bug. ***
Changing product and version.
- None of them handle this alternative signal handler, overhauling signal handler unwinders to fix.
*** Bug 117028 has been marked as a duplicate of this bug. ***
I see this is "Platform: All", but I thought this was fixed on IA64 with the libunwind based gdb?
Yes, libunwind fixes the ia64 specific backtrace. Unfortunatly it doesn't fix step/finish/return/next when presented with such a stack :-( Both architecture specific and generic fixes are needed.
*** Bug 121656 has been marked as a duplicate of this bug. ***
hijack summary to mirror for 121656
Can somebody explain to me why most bugs related to this one are secret? I fail to see how being unable to walk the stack in gdb can relate to anything security sensitive, especially bug 121656 that has been closed as a duplicate of this one. It's quite annoying that almost every time I get an e-mail about this bug it says the equivalent of "Something changed but I won't tell you what, nyah, nyah.".
----- Additional Comments From manoji@us.ibm.com(prefers email via manjo@austin.ibm.com) 2004-09-02 15:50 ------- *** Bug 8850 has been marked as a duplicate of this bug. ***
This bug is NEEDINFO, but I cannot find any request for more info. Is any information needed, and if so, what, or has the Status just not been updated?
changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|RHEL3_U4 |RHEL3_U6 ------- Additional Comments From corryk@us.ibm.com(prefers email via kevcorry@us.ibm.com) 2005-07-11 15:22 EDT ------- RHEL3-U4 is already out, so moving the target-milestone to RHEL3-U6.