Re: [rfc, frame] Move the corrupt frame checks earlier

[Daniel Jacobowitz <drow@false.org>]

On Sun, Aug 20, 2006 at 04:32:40PM +0200, Mark Kettenis wrote:
> > Date: Sat, 19 Aug 2006 11:56:54 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > This patch is a follow-on to the unwind_stop_reason patch, although not
> > actually dependent.  It moves the frame-went-inner and frame-same-ID
> > checks earlier in the backtrace process.  Although they move down
> > in the function, they also check PREV rather than THIS.
> > 
> > The benefit of doing this is that we display the stop reason before,
> > rather than after, the frame we've decided is corrupt.  For instance,
> > suppose we have two frames with the same ID.  That means they have the
> > same CFA and the same function.  In other words, the same stack frame.
> > So the second backtrace entry will be a duplicate of the first. There's
> > no added value in displaying it, and logically it doesn't need to exist
> > on the frame chain.
> 
> Sorry it's not clear to me what exactly the effect is.  Does it make
> frames disappear that are there now?  I wouldn't like that, since it
> the past I clearly remember getting useful information out of the last
> frame printed in a bad backtrace.
> 
> Perhaps you can give an example of the old & new behaviour?

It does eliminate the last frame from the backtrace when displaying one
of these errors, yes.  There is one bit of potentially useful
information there, but it isn't lost.

Suppose you've got a backtrace that looks like this.

#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7ea61cb in poll () from /lib/tls/i686/cmov/libc.so.6
#2  0x0810c713 in gdb_do_one_event ()
#3  0x08109a43 in catch_errors ()
#4  0x080b8c13 in _initialize_tui_hooks ()
#5  0x08109d1d in current_interp_command_loop ()
#6  0x08077a3b in main ()

Then I manually stitch up the stack frame, to get this:

#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7ea61cb in poll () from /lib/tls/i686/cmov/libc.so.6
#2  0x0810c713 in gdb_do_one_event ()
#3  0x0810c713 in gdb_do_one_event ()
Previous frame identical to this frame (corrupt stack?)

(By editing the saved %eip and %ebp for frame #2).

The question is, does frame #3 in that second backtrace display any
information other than what the error message does?  It's got the same
CFA and PC, so it's literally a duplicate of the previous frame.

The one small difference is that you can go to frame 2 and 3, and type
info reg ebx, and get different results; that's because we have the
prev_register.  But you can also go to frame 2 and type info frame, and
that will show you where the saved registers for this frame are; which
I think is just as useful.

For the "frame id inner" check it's more of a tossup.  Now there's
extra information in the frame output not in the error message:
we'll print out the unwound value of PC.  But both the address of
the saved eip and the value of the saved eip are available in info
frame.

My feeling is that this corrupt frame is not part of the backtrace,
and if you want to know more about it, having to type "info frame NUM"
is just fine.

Maybe I should add a bit to the manual about dealing with failed
backtraces?  Whether they're program corruption or GDB failure,
the useful things to do are the same.

-- 
Daniel Jacobowitz
CodeSourcery