Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Roland Schwingel <roland.schwingel@onevision.de>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb@sourceware.org, gdb@sources.redhat.com
Subject: Re: gdb stack trace problems (Addendum)
Date: Mon, 25 Apr 2005 12:35:00 -0000	[thread overview]
Message-ID: <426CA356.60901@onevision.de> (raw)

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


WARNING: multiple messages have this Message-ID
From: Roland Schwingel <roland.schwingel@onevision.de>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb@sourceware.org, gdb@sources.redhat.com
Subject: Re: gdb stack trace problems (Addendum)
Date: Mon, 25 Apr 2005 08:00:00 -0000	[thread overview]
Message-ID: <426CA356.60901@onevision.de> (raw)
Message-ID: <20050425080000.Gg6asTNCXcxg7vfOY4C4rAXnfNRbowip5Cfk-7qOTPA@z> (raw)

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


             reply	other threads:[~2005-04-25  8:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-25 12:35 Roland Schwingel [this message]
2005-04-25  8:00 ` Roland Schwingel
2005-04-25 19:35 ` Mark Kettenis
2005-04-25 19:45   ` Daniel Jacobowitz
2005-04-25 20:37     ` Mark Kettenis
  -- strict thread matches above, loose matches on Subject: below --
2005-05-10  8:39 Roland Schwingel
2005-05-10  8:38 Roland Schwingel
2005-05-02  7:04 Roland Schwingel
2005-05-08 13:31 ` Mark Kettenis
2005-05-08 23:20   ` Christopher Faylor
2005-05-09  4:48     ` Eli Zaretskii
2005-05-09  5:26       ` Christopher Faylor
2005-05-09  5:30     ` Stan Shebs
2005-04-26 11:53 Roland Schwingel
2005-04-26  9:11 Roland Schwingel
2005-04-19  8:01 Roland Schwingel
     [not found] ` <4268B942.5080300@onevision.de>
2005-04-22 17:51   ` Mark Kettenis
2005-04-19  7:34 Roland Schwingel
2005-04-19  7:45 ` Mark Kettenis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=426CA356.60901@onevision.de \
    --to=roland.schwingel@onevision.de \
    --cc=gdb@sources.redhat.com \
    --cc=gdb@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox