This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb/2311: bad stackframe, corrupt backtrace, stacktrace


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]