Re: [RFC] Infinite backtraces...

[Randolph Chung <randolph@tausq.org>]

> While working on something else, I just stumbled on this (in gdb 5.3):
> 
>   /* If this is a threaded application, and we see the
>      routine "__pthread_exit", treat it as the stack root
>      for this thread. */
> 
> I haven't run this through the debugger to confirm it, but it looks
> like we used to stop the unwinding by using the name of the symbol
> associated to the frame. Not very elegant, to say the least, but
> could be effective for hpux (it would no longer be just architecture
> dependent).

erk, yuck :)

> > in your particular case, i'm curious to know how we get from a pc=0
> > frame to a previous frame. that seems like a bug to me?
> 
> Not sure. I haven't really looked at this in details, since this part
> of the callstack was bogus anyway. But my guess is that the fallback
> unwinder kicked in (since we shouldn't find any unwind entry for that
> PC), and just unwound blindly.

yeah, but i would have expected that you should get an error when 
unwinding from 0 ("Cannot find bounds of current function ..."). this
should automatically stop the backtrace.

would you mind sending me the output of "info reg" frame frame 5 and 6,
"maint print unwind __pthread_create_system" and "disassemble
__pthread_create_system"?

> I would prefer that the new method by called in addition to the current
> logic. The reason being that, for architectures overriding the default,
> they would have to reimplement that part again in addition of doing their
> own magic.

well, they can call the default handler afterwards. but anyway, this is
just a minor detail.

> Frame #2 is a duplicate of #1, although it's hard to see if you don't
> know the GNAT encoding. Same for frame #4 being a duplicate of #3.
> Same for #5 and #6.
> 
> These frames are referring to stubs. With 5.3, we skipped these stubs.
> Do you know if putting them here was intentional? I find them confusing,
> so I'd like to remove them.

yes and no.... i don't know all the history, but i believe the new frame
code in gdb 6.x is more explicit about unwinding through various frames,
including stub frames. on hpux export stubs show up in backtraces
because they occupy stack space. (hppa-linux doesn't use export stubs).
i don't like it either, but not sure what we can do about it.

see:
http://sources.redhat.com/ml/gdb-patches/2004-05/msg00741.html

another possibility is that you found a bug; we still have lots of bugs
on hpux :(

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/