Re: [RFC] Infinite backtraces...

[Joel Brobecker <brobecker@adacore.com>]

> >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