This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] Infinite backtraces...
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