This is the mail archive of the
mailing list for the GDB project.
Re: [RFC][Python] gdbpy_frame_stop_reason_string bug
On Wednesday 12 October 2011 16:17:32, Kevin Pouget wrote:
> On Wed, Oct 12, 2011 at 4:52 PM, Pedro Alves <firstname.lastname@example.org> wrote:
> > On Wednesday 12 October 2011 15:02:20, Kevin Pouget wrote:
> >> I wanted to discuss the best way to solve this bug before going any
> >> further in the development:
> >> > (gdb) py print gdb.frame_stop_reason_string(2)
> >> > /home/kevin/travail/git/gdb/gdb/frame.c:2372: internal-error: Invalid frame stop reason
> >> > A problem internal to GDB has been detected,further debugging may prove unreliable.
> >> I prepared the attached patch, which requires to change
> >> 'internal_error' to a simple 'error' (I assume that it can't break
> >> anything because it ends up calling `exit()', but I didn't check yet),
> >> but "Frame.unwind_stop_reason ()" easily returns 'invalid frame stop
> >> reason', for instance
> > 2 == UNWIND_OUTERMOST. Why would that be invalid?
> > frame_stop_reason_string isn't handling this, nor UNWIND_NO_REASON.
> > Is there a reason for that? I think something like the below
> > patch would be much better. This _is_ an internal error / bug after
> > all. (We could leave UNWIND_FIRST_ERROR as part of the enum with
> > `UNWIND_UNAVAILABLE = UNWIND_FIRST_ERROR', I don't have that
> > a strong preference.) Better yet could be to define the
> > values/strings in the same place in a .def file.
> > Where do magical the numbers come from? I hope we've not
> > blessed them as stable.
> yes, makes perfectly sense, thanks
> the numbers come from there:
Yeah, that much I had found, but I got stuck looking for the enum
versions of those.
> ... I don't know if changing these numbers would be considered as a
> backward incompatibility ... ?
Sigh, I hope not.
> From: Phil Muldoon <email@example.com>
> > Why not use the supplied gdb constants in this case? "2" does not map
> > to any enum.
> > IE gdb.FRAME_UNWIND_NO_REASON
> it looks like these enums are not documented, are they? I can't grep
> 'FRAME_UNWIND_NO_REASON' in gdb.texinfo
> ('2' was a bad example, but the reason why I first used '0' was
> because it was returned by Frame.unwind_stop_reason(), as depicted in
> the first mail)
> by the way, python print
> gdb.frame_stop_reason_string(gdb.FRAME_UNWIND_FIRST_ERROR) crashes the
> same way, there is certainly a few more lines to fix on the Python
The patch I posted supposedly fixes that, my making
FRAME_UNWIND_FIRST_ERROR an internal alias for a real
value (..._UNAVAILABLE), so that there are no "holes" in
the enum values.