Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 76645 - gdb unable to give stack traces across signal handler (UML)
Summary: gdb unable to give stack traces across signal handler (UML)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gdb
Version: 8.0
Hardware: athlon
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Elena Zannoni
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-10-24 15:34 UTC by Mike Shaver
Modified: 2015-01-08 00:01 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-03-10 16:43:54 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:126 normal SHIPPED_LIVE Updated gdb package includes bug fixes, updated IA64 libunwind package 2004-05-18 04:00:00 UTC

Description Mike Shaver 2002-10-24 15:34:21 UTC
When running user-mode Linux under gdb in Red Hat 8.0, I am unable to get a
stack trace that goes back before a signal handler runs.

Only the functions called from the signal handler (in this case, |segv| and
|panic|) are visible when stopped at a breakpoint in |panic|.  Manual walking of
$ebp will let me find calling PCs, so the stack hasn't been trashed.

I've tried with both
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)
and
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

with similar results.  I will try to find time to try with a RH7.3-era gdb to
see if the results are different.

The user-mode Linux in question is built from the Red Hat 2.4.18-14 kernel, with
some VFS patches.

gdb-5.2.1-4

Comment 1 Elena Zannoni 2002-10-31 19:26:59 UTC
Could you attach a copy of gdb's backtrace output? I suspect this is a known
bug, and it is being fixed in the FSF gdb development branch.

Thanks
Elena

Comment 2 Mike Shaver 2002-10-31 19:38:00 UTC
Now that I've started using the compat-gcc-7.3 gcc to build my kernel, the
problem has gone away.  I can try to restore the old setup, if you really need
me too, but the stack trace would look very much like:

(gdb) bt
#0 0xdeadbeef in panic (args to panic) at panic_source.c:42
#1 0xcafebabe in segv (args to segv) at segv_source.c:1977
(gdb)

Trying to go up from frame 1 would tell me 

(gdb) up
Initial frame selected; you cannot go up.

I'll try a build with 3.2 this weekend, once I'm finished with my current
development task.

Comment 3 Elena Zannoni 2002-10-31 19:56:20 UTC
Thanks, could I also bribe you in trying the current FSF gdb on
sources.redhat.com/gdb?
A fix was recently checked in for this problem. (Ignore the 5.3 branch).

Elena


Comment 4 Mike Shaver 2002-10-31 19:58:05 UTC
Sure.  Once I've torched my development environment, I don't mind dancing on the
ashes. =)

Can I just grab a today-or-later snapshot, or should I really pull from CVS?

Comment 5 Elena Zannoni 2002-10-31 20:21:22 UTC
The snapshots should be ok. 


Comment 6 John Flanagan 2004-05-18 19:15:44 UTC
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-126.html



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