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:
Clone Of:
Environment:
Last Closed: 2004-03-10 16:43:54 UTC
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:126 0 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.