[rfc, v2] Fix frame_id_inner comparison false positives

Daniel Jacobowitz drow@false.org
Thu Aug 21 20:16:00 GMT 2008


On Thu, Aug 21, 2008 at 09:42:35PM +0200, Ulrich Weigand wrote:
> > On the other hand, if the user has set a backtrace depth limit, then
> > frame_find_by_id may fail if a function with a deep stack is called.
> > We'll discard the dummy frame when it's still valid and get an extra
> > sigtrap.  This behavior should be straightforward to write a test case
> > for: set the backtrace limit to ten, call a function which recurses
> > twenty times and then hits a breakpoint, call another function, raise
> > the backtrace limit and see if we've lost the outer dummy frame.
> 
> This seems simply a bug of frame_find_by_id.  This function should be
> using get_prev_frame_1 instead of get_prev_frame.  There is no reason
> why re-identifying a frame you had already selected previously should
> suddenly fail just because some user-interface setting was changed ...

Well, here I'm not sure about.  I don't consider 'set backtrace limit'
to be just a user interface change; we use it as a safety net.

For example.  Suppose you have an unterminated M68K stack, and the top
says '0xffffffff'.  GDB will see that, assume it's a return address,
check whether there's code there, decide there isn't (memory read
fails), and use the stub unwinder - which adds 4 to the stack pointer,
restores the return address, and goes along its merry recursive way.

This is a bug in the 68k unwinder, of course.  But it's a very easy
bug to have and a very hard bug to catch.  So I don't like algorithms
that make us unwind past the immediate frame.

The only place your patch switched to using frame_find_by_id instead
of frame_id_inner was the dummy frame check, though.  So maybe the
right thing to do is just to remove that stale dummy frame check, and
clear the dummy list when we get a new inferior?  And stick to
get_prev_frame, at least for the moment.

Other than that, your logic looks entirely right to me.  I like
the clever corruption check.

-- 
Daniel Jacobowitz
CodeSourcery



More information about the Gdb-patches mailing list