This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] Infinite backtraces...
> >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?
We create the ID of this frame. Then create the previous frame.
I think I'm starting to see how I was confused. Going back to my
initial example, we have:
#0 simple.break_me () at simple.adb:27
#1 0x0000a2cc in simple.caller (<_task>=0x4001c3a0) at simple.adb:21
#2 0x0000a268 in simple__callerB___2 () at simple.adb:18
#3 0x00017184 in system.tasking.stages.task_wrapper ()
#4 0x00017058 in system__tasking__stages__task_wrapper ()
#5 0x7aee0f60 in __pthread_create_system () from /usr/lib/libpthread.1
#6 0x7aee0f08 in __pthread_create_system () from /usr/lib/libpthread.1
#7 0x00000000 in ?? ()
Imagine we are at frame #6, and try to go up one frame. So what happens
is that we compute the ID of frame #6, and then, assuming all the sanity
checks are ok, create frame #7.
What you are suggesting is that we return a null frame ID for frame
#6, correct? What I thought you were saying is that we return a null
frame ID for frame *7*, which of course should never exist.
> A null-ID indicates that the frame can't be unwound from, not that it is
> necessarially itself invalid.
I think that's the key I didn't understand.
> There are two objectives here:
>
> - stop a run-away stack
> which means correctly determining it's end
This is the problem we're trying to solve.
> - deciding, for possibly cosmetic reasons, which frames to list
> which means stopping the list at main by default
This part, I think, is fine.
> 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.
Absolutely.
Thanks for the explanation! Hopefully I got it right this time.
--
Joel