This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb stack trace problems (Addendum)
- From: Roland Schwingel <roland dot schwingel at onevision dot de>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: gdb at sourceware dot org, gdb at sources dot redhat dot com
- Date: Mon, 25 Apr 2005 09:59:18 +0200
- Subject: Re: gdb stack trace problems (Addendum)
Hi...
Mark Kettenis wrote on 22.04.2005 19:51:14:
> Hi Mark...
>
> Have you already had some time to look into it?
>
> I did, but I didn't have find the time to reply yet ;-).
Thank you very much...
> Anyway, there is a serious problem here. The code you show is
> basically undebuggable.
> [...]
> The only thing we can do here is trust the frame pointer, like we used
> to do in the old days. The problem with that is that it's very likely
> to (silently) skip some function calls. In your particular example it
> probably would appear as if your code called SleepEx directly and
> there would be no trace of Sleep at all. That can be quite puzzling.
>
> I'm thinking about adding an option to instruct gdb to "trust" the
> frame pointer. I'm not going to make it the default though. I really
> prefer seeing an abviously wrong backtrace over gdb silently skipping
> function calls in its backtraces.
Well the present situation is quite problematic for us. In past days
(gdb 5.3)
when an application crashed we had a quite accurate backtrace. It wasn't
wrong (for us). Finding/Fixing bugs was very easy. GDB has been
very useful here.
With gdb 6.x we are no longer able to get a backtrace in these cases (in
about
95% of all cases). This is a serious problem and makes gdb 6.x quite
unusable
for us (and maybe others on windows). Having at least an option for enabling
that feature would be IMHO absolutely necessary. I wonder why other users
on windows haven't complained earlier about this problem.
So will you implement such an option? I am quite unfamiliar with the
internals
of gdb's stack unwinding, so I am not of much help here. But whenever I can
do something to help to fix this I am happily volunteering to do so.
Thanks again for your help Mark!
Roland