This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
gdb/2311: bad stackframe, corrupt backtrace, stacktrace
- From: mnemo at minimum dot se
- To: gdb-gnats at sources dot redhat dot com
- Date: 8 Sep 2007 16:24:24 -0000
- Subject: gdb/2311: bad stackframe, corrupt backtrace, stacktrace
- Reply-to: mnemo at minimum dot se
>Number: 2311
>Category: gdb
>Synopsis: bad stackframe, corrupt backtrace, stacktrace
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Sat Sep 08 16:28:02 UTC 2007
>Closed-Date:
>Last-Modified:
>Originator: mnemo@minimum.se
>Release: unknown-1.0
>Organization:
>Environment:
>Description:
Compile this program in GCC on GNU/Linux with debug symbols:
void asm_jmp_zero(void)
{
__asm__ ("jmp 0\n\t");
}
int main(void)
{
asm_jmp_zero();
return 0;
}
Then run it in GDB:
(gdb) r
Starting program: /home/mnemo/Desktop/trace_test/sigsegv
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1210053952 (LWP 10014)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210053952 (LWP 10014)]
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0xbfc2a368 in ?? ()
#2 0x08048391 in main () at main.c:8
(gdb)
Notice that the #1 stackframe isn't being properly printed. The expected behaviour is that #1 is presented as asm_jmp_zero function because that's what it represents.
This test case is a very much narrowed down and simplied version of a very nasty bug I've been struggling with lately.
I'd really appreciate if some uber GDB hacker could make GDB handle these situations.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: