Re: gdb/2311: bad stackframe, corrupt backtrace, stacktrace

Re: gdb/2311: bad stackframe, corrupt backtrace, stacktrace

[drow]

Synopsis: bad stackframe, corrupt backtrace, stacktrace

State-Changed-From-To: open->closed
State-Changed-By: drow
State-Changed-When: Sat Sep  8 16:54:31 2007
State-Changed-Why:
    Testcase reduced too far, I suspect - this is not a bug.

http://sourceware.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=2311

Re: gdb/2311: bad stackframe, corrupt backtrace, stacktrace

[Daniel Jacobowitz]

The following reply was made to PR gdb/2311; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: mnemo@minimum.se
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2311: bad stackframe, corrupt backtrace, stacktrace
Date: Sat, 8 Sep 2007 12:54:04 -0400

 On Sat, Sep 08, 2007 at 04:24:24PM -0000, mnemo@minimum.se wrote:
 > 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.
 
 No, it doesn't.  It is impossible to print asm_jmp_zero in this case
 because jmp does not leave a return address on the stack.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

gdb/2311: bad stackframe, corrupt backtrace, stacktrace

[mnemo]

>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: