Exception on GDB "-stack-list-frames"

[John Dallaway]

Hi

I am observing missing backtraces for some threads when debugging using
CDT 4.0.1 and GDB 6.1. Looking at the GDB/MI traffic, I note that the
backtraces are missing because "-stack-list-frames" returns:

^error,msg="Previous frame inner to this frame (corrupt stack?)"

which triggers an exception.

If I manually invoke this MI command a second time it succeeds.

I also note that Thread::getStackFrameCount() will retry if the MI
command "-stack-info-depth" triggers a similar exception.

What is the reason for the error message? Should
Thread::getStackFrames() also retry on initial failure?

John Dallaway

[Daniel Jacobowitz]

Post by John Dallaway
Hi
I am observing missing backtraces for some threads when debugging using
CDT 4.0.1 and GDB 6.1. Looking at the GDB/MI traffic, I note that the
^error,msg="Previous frame inner to this frame (corrupt stack?)"
which triggers an exception.

Please consider upgrading GDB; this won't be displayed as an error in
GDB 6.7.

[John Dallaway]

Hi Daniel

Thank you for your reply. Updating to GDB 6.7 is not a viable option for
me at present. I must workaround the issue. Do you understand why these
error messages arise and under what conditions an MI command might need
to be repeated? My experimentation suggests that switching to a new
thread using "-thread-select" and then switching back to the original
thread is sufficient to trigger the error on a subsequent
"-stack-list-frames" command.

I could modify the appropriate method in the Threads class to retry
"-stack-list-frames" in the same way that "-stack-info-depth" is
retried, but there may be other commands that require a similar treatment...

John Dallaway


-------- Original Message --------
Subject: cdt-debug-dev Digest, Vol 34, Issue 6
Date: Fri, 21 Dec 2007 12:00:14 -0500 (EST)
From: cdt-debug-dev-request-j9T/***@public.gmane.org
Reply-To: cdt-debug-dev-j9T/***@public.gmane.org
To: cdt-debug-dev-j9T/***@public.gmane.org

------------------------------

Message: 2
Date: Thu, 20 Dec 2007 12:32:05 -0500
From: Daniel Jacobowitz <drow-***@public.gmane.org>
Subject: Re: [cdt-debug-dev] Exception on GDB "-stack-list-frames"
To: CDT Debug developers list <cdt-debug-dev-j9T/***@public.gmane.org>
Message-ID: <20071220173205.GA19931-***@public.gmane.org>
Content-Type: text/plain; charset=us-ascii

Post by John Dallaway
Hi
I am observing missing backtraces for some threads when debugging using
CDT 4.0.1 and GDB 6.1. Looking at the GDB/MI traffic, I note that the
^error,msg="Previous frame inner to this frame (corrupt stack?)"
which triggers an exception.

Please consider upgrading GDB; this won't be displayed as an error in
GDB 6.7.

[Daniel Jacobowitz]

Post by John Dallaway
Hi Daniel
Thank you for your reply. Updating to GDB 6.7 is not a viable option for
me at present. I must workaround the issue. Do you understand why these
error messages arise and under what conditions an MI command might need
to be repeated? My experimentation suggests that switching to a new
thread using "-thread-select" and then switching back to the original
thread is sufficient to trigger the error on a subsequent
"-stack-list-frames" command.

GDB maintains a persistent cache of frames, but only one at a time.
The error occurred while populating the cache, but not while
displaying it. So any command which walks the stack is subject to
this problem.

[Stefan Bylund]

Hi John,

We are using GDB 6.3 and have stumbled over this issue as well. If you
have the option of rebuilding GDB you can simply replace a few error()
calls with warning() calls to make CDT happier. If you're interested, I
can look up exactly which lines we had to change in this way.

I think that the cause for this problem is that GDB 6.x doesn't always
realize when it has reached the bottom of the call stack and tries to
unwind the last stack frame multiple times. IMHO, calling error() at
this point is too defensive.

Regards,
Stefan

Post by John Dallaway
Hi Daniel
Thank you for your reply. Updating to GDB 6.7 is not a viable option for
me at present. I must workaround the issue. Do you understand why these
error messages arise and under what conditions an MI command might need
to be repeated? My experimentation suggests that switching to a new
thread using "-thread-select" and then switching back to the original
thread is sufficient to trigger the error on a subsequent
"-stack-list-frames" command.
I could modify the appropriate method in the Threads class to retry
"-stack-list-frames" in the same way that "-stack-info-depth" is
retried, but there may be other commands that require a similar treatment...
John Dallaway
-------- Original Message --------
Subject: cdt-debug-dev Digest, Vol 34, Issue 6
Date: Fri, 21 Dec 2007 12:00:14 -0500 (EST)
------------------------------
Message: 2
Date: Thu, 20 Dec 2007 12:32:05 -0500
Subject: Re: [cdt-debug-dev] Exception on GDB "-stack-list-frames"
Content-Type: text/plain; charset=us-ascii

Post by John Dallaway
Hi
I am observing missing backtraces for some threads when debugging using
CDT 4.0.1 and GDB 6.1. Looking at the GDB/MI traffic, I note that the
^error,msg="Previous frame inner to this frame (corrupt stack?)"
which triggers an exception.

Please consider upgrading GDB; this won't be displayed as an error in
GDB 6.7.

[Øyvind Harboe]

Post by John Dallaway
Hi Daniel
Thank you for your reply. Updating to GDB 6.7 is not a viable option for
me at present. I must workaround the issue. Do you understand why these
error messages arise and under what conditions an MI command might need
to be repeated? My experimentation suggests that switching to a new
thread using "-thread-select" and then switching back to the original
thread is sufficient to trigger the error on a subsequent
"-stack-list-frames" command.
I could modify the appropriate method in the Threads class to retry
"-stack-list-frames" in the same way that "-stack-info-depth" is
retried, but there may be other commands that require a similar treatment...

Are these pointers any help?

https://lists.berlios.de/pipermail/openocd-development/2007-December/000414.html

I've modified my local CDT to have a minimum stack depth of 3, that helps...

[Daniel Jacobowitz]

Post by Øyvind Harboe
Are these pointers any help?
https://lists.berlios.de/pipermail/openocd-development/2007-December/000414.html

I hope that you read my reply, in that your #1 is already done. If
you have an example to the contrary please report it. To the GDB
developers!

I see a lot of posts on the CDT development lists about bugs in GDB
that do not end up as GDB bug reports. This is really aggravating.
We can't fix what people don't tell us about.

[Øyvind Harboe]

Post by Daniel Jacobowitz

Post by Øyvind Harboe
Are these pointers any help?
https://lists.berlios.de/pipermail/openocd-development/2007-December/000414.html

I hope that you read my reply, in that your #1 is already done. If
you have an example to the contrary please report it. To the GDB
developers!

Super! I'll try CVS HEAD from GDB and take it for a spin when I get back
into the office.

Have you got a pointer to patch in a mailing list or something?


I recall pulling down the latest version of GDB to see if this was still a
problem ca. 1 month back... Looks like the GDB web site is closed for Xmas :-)
I'll have a look at the bug reporting procedures later on...

Post by Daniel Jacobowitz
I see a lot of posts on the CDT development lists about bugs in GDB
that do not end up as GDB bug reports. This is really aggravating.
We can't fix what people don't tell us about.

Fear? Extraordinary claims require extraordinary evidence... It's quite
a way from "I pushed this button in CDT and that happend" to putting
together an actionable report to GDB. In my case, I was out of time
when I kinda figured out what was happening...

[Daniel Jacobowitz]

Post by Øyvind Harboe

Post by Daniel Jacobowitz

Post by Øyvind Harboe
Are these pointers any help?
https://lists.berlios.de/pipermail/openocd-development/2007-December/000414.html

I hope that you read my reply, in that your #1 is already done. If
you have an example to the contrary please report it. To the GDB
developers!

Super! I'll try CVS HEAD from GDB and take it for a spin when I get back
into the office.
Have you got a pointer to patch in a mailing list or something?

I believe it was:
http://sourceware.org/ml/gdb-patches/2006-08/msg00166.html

If you've seen it since then, there may be another problem I don't
know about. It happens :-)

[Øyvind Harboe]

Post by Daniel Jacobowitz

Post by Øyvind Harboe
Super! I'll try CVS HEAD from GDB and take it for a spin when I get back
into the office.
Have you got a pointer to patch in a mailing list or something?

http://sourceware.org/ml/gdb-patches/2006-08/msg00166.html
If you've seen it since then, there may be another problem I don't
know about. It happens :-)

I think it is fixed, but I need more time to test... I've updated the
CDT bug report
with a reference.

Thanks!