Re: gdb/321: stack trace reports incorrect caller to abort()

[Joel Brobecker <brobecker at gnat dot com>]

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

From: Joel Brobecker <brobecker@gnat.com>
To: drow@sources.redhat.com, brobecke@sources.redhat.com,
	gdb-prs@sources.redhat.com, liblit@acm.org,
	nobody@sources.redhat.com, gdb-gnats@sources.redhat.com
Cc:  
Subject: Re: gdb/321: stack trace reports incorrect caller to abort()
Date: Tue, 16 Jul 2002 11:10:33 -0700

 > State-Changed-Why:
 >     Joel, I believe this PR is the same issue you fixed in:
 >     2002-07-02  Joel Brobecker  <brobecker@gnat.com>
 >     
 >             * frame.h (frame_address_in_block): New function.
 >     
 >             * blockframe.c (frame_address_in_block): New function extracted
 >             from get_frame_block().
 >             (get_frame_block): Use frame_address_in_block().
 >             (block_innermost_frame): Use frame_address_in_block() to match
 >             the frame pc address against the block boundaries rather than
 >             the frame pc directly. This prevents a failure when a frame pc
 >             is actually a return-address pointing immediately after the end
 >             of the given block. 
 >     
 >     
 >     I still see a problem here, though:
 >     #0  0x40050741 in kill () from /lib/libc.so.6
 >     #1  0x40050424 in raise () from /lib/libc.so.6
 >     #2  0x40051b81 in abort () from /lib/libc.so.6
 >     #3  0x0804844c in b () at bug.c:15
 >     #4  0x4004014f in __libc_start_main () from /lib/libc.so.6
 >     
 >     But info frame for #3 correctly says that we are in main,
 >     not in b().
 >     
 >     Is this a case your patch was supposed to handle?
 
 This appears to be fixed. I tried on RH 7.1 and 7.2 using gcc 2.96 20000731,
 using today's version of gdb (GNU gdb 2002-07-16-cvs).
 
 I had to comment one call to a() in order to avoid any instruction
 padding, but the bactrace shows that the call to abort comes from main:
 
       (gdb) bt
       #0  0x40051801 in __kill () at __kill:-1
       #1  0x400515da in raise (sig=6) at ../sysdeps/posix/raise.c:27
       #2  0x40052d82 in abort () at ../sysdeps/generic/abort.c:88
       #3  0x08048478 in main (argc=1, argv=0xbffff78c) at bug.c:15
       #4  0x40040177 in __libc_start_main (main=0x8048468 <main>, argc=1, 
           ubp_av=0xbffff78c, init=0x80482e0 <_init>, fini=0x80484c0 <_fini>, 
           rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff77c)
           at ../sysdeps/generic/libc-start.c:129
       (gdb) info frame 3
       Stack frame at 0xbffff718:
        eip = 0x8048478 in main (bug.c:15); saved eip 0x40040177
        called by frame at 0xbffff758, caller of frame at 0xbffff708
        source language c.
        Arglist at 0xbffff718, args: argc=1, argv=0xbffff78c
        Locals at 0xbffff718, Previous frame's sp in esp
        Saved registers:
         ebp at 0xbffff718, eip at 0xbffff71c
 
 I checked that the call to abort was the last instruction in function
 main using "gcc -S", and that there was no instruction padding using
 "objdump --disassemble bug":
 
       08048468 <main>:
        8048468:       55                      push   %ebp
        8048469:       89 e5                   mov    %esp,%ebp
        804846b:       83 ec 08                sub    $0x8,%esp
        804846e:       e8 ed ff ff ff          call   8048460 <a>
        8048473:       e8 b0 fe ff ff          call   8048328 <_init+0x48>
       
       08048478 <b>:
        8048478:       55                      push   %ebp
        8048479:       89 e5                   mov    %esp,%ebp
 
 -- 
 Joel