Bug 137240 - gdb cannot always backtrace through signal handler
Summary: gdb cannot always backtrace through signal handler
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gdb   
(Show other bugs)
Version: 2
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alexandre Oliva
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-26 21:46 UTC by Ben Greear
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version: FC5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-28 21:02:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Ben Greear 2004-10-26 21:46:35 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040913

Description of problem:
My program catches SIGSEGV (and similar) and prints out
a small bit of debugging before it asserts to create a core
file.  On RedHat9 I can use gdb to backtrace through the
signal call back to the method that caused the original SIGSEGV,
but with FC2, I get this instead:

(gdb) bt
#0  0x0850cce1 in kill ()
#1  0x0853e69c in raise ()
#2  0x00000006 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(gdb)

The actual bug that caused this core was a de-reference of
a null pointer to an object, ie:
MyObject foo* = NULL;
foo->something(); // Crashes


The code is compiled with -O2 and -g, among other flags.

The kernel is 2.6.9 + my networking patches.




Version-Release number of selected component (if applicable):
gdb-t.0post-0.20040223.19

How reproducible:
Sometimes

Steps to Reproduce:
1. It is reproducible every time with my big, proprietary app.  It is
not reproducible with a very simple test case.  I can provide the core
file and executable if that helps.

2.
3.
    

Additional info:

Comment 1 Matthew Miller 2005-04-26 16:35:15 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 2 Ben Greear 2006-09-28 21:02:44 UTC
this was fixed, seems to work in FC5 at least.


Note You need to log in before you can comment on or make changes to this bug.