Re: [RFC][Python] gdbpy_frame_stop_reason_string bug

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 12 October 2011 16:17:32, Kevin Pouget wrote:
> On Wed, Oct 12, 2011 at 4:52 PM, Pedro Alves <pedro@codesourcery.com> 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:
> http://sourceware.org/gdb/onlinedocs/gdb/Frames-In-Python.html#index-unwind_005fstop_005freason-on-Frame-1870

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 <pmuldoon@redhat.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

Yeah.

> 
> ('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
> side

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.

-- 
Pedro Alves