Re: [RFC] Infinite backtraces...

[Andrew Cagney <cagney@gnu.org>]

Joel Brobecker wrote:
>>Yes, gdb already creates the frame object and then later constructs the 
>>frame ID.  The build has been reduced to:
>>
>>	prev_frame = malloc ();
>>	prev_frame->next = this_frame;
>>	return prev_frame;
>>
>>Also note that, unlike the past, the frame ID is separate to the ``frame 
>>base'' the former can be NULL while the later is still valid.
>>
>>
>>>And then, after building each new frame, we display the information
>>>for that new frame.
>>
>>It is what lets us "up" on to an apparently corrupt frame.
> 
> 
> Reviewing the code that does the backtrace, I don't see how this
> would work. We're at the oldest frame, trying to unwind from it.
> So we compute its ID, and then create the previous frame.

Which ID, this or prev?

GDB computes this-ID does some sanity checks and then, assuming it is 
valid, blindly creates prev frame.

> I didn't find where in our code, in particular in stack.c, we're
> prepared to deal with a frame that we later find is invalid (via a null
> frame ID). Perhaps it is simpler to modify the build sequence above to
> add the computation of the frame ID and use that as a guard before
> creating the new frame?

A null-ID indicates that the frame can't be unwound from, not that it is 
necessarially itself invalid.

I think you're describing the old logic:

    if (prev frame ID valid)
	then return prev frame

it had the problem that it wasn't possible to examine that terminal, 
possibly corrupt, frame.  I deleted the test (and there was much 
celebration :-).

There are two objectives here:

- stop a run-away stack
which means correctly determining it's end

- deciding, for possibly cosmetic reasons, which frames to list
which means stopping the list at main by default

when it comes to the true outer-most frame there's always going to be 
fuz, as long as it terminates I think we're ok.

Andrew