Re: [RFC] Infinite backtraces...

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Dec 03, 2004 at 01:57:45PM -0800, Joel Brobecker wrote:
> > >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.

I'd suggest that you return a null frame ID from frame *5* actually.
Is there a reason not to do that?  Certainly a bit of caution is called
for, but if GDB has the knowledge that a particular bit of code can
never be backtraced through...

There's an equivalent function in the glibc thread libraries 
for starting a thread, which should never be backtraced through.  Note
that we can't do a similar thing for clone unless the target's library
provides a symbol distinct from clone to use; we have to be able to
backtrace from clone itself.

-- 
Daniel Jacobowitz