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