Bug 76645 – gdb unable to give stack traces across signal handler (UML)

Bug 76645 - gdb unable to give stack traces across signal handler (UML)

Summary:	gdb unable to give stack traces across signal handler (UML)

Status:	CLOSED ERRATA

Aliases:	None

Product:	Red Hat Linux
Classification:	Retired
Component:	gdb (Show other bugs)
Sub Component:
Version:	8.0
Hardware:	athlon Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Elena Zannoni
QA Contact:	Jay Turner
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2002-10-24 11:34 EDT by Mike Shaver
Modified:	2015-01-07 19:01 EST (History)
CC List:	1 user (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2004-03-10 11:43:54 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Mike Shaver 2002-10-24 11:34:21 EDT

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 14:26:59 EST

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 14:38:00 EST

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 14:56:20 EST

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 14:58:05 EST

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 15:21:22 EST

The snapshots should be ok.

Comment 6 John Flanagan 2004-05-18 15:15:44 EDT

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.