Re: [RFC][Python] gdbpy_frame_stop_reason_string bug

[Kevin Pouget <kevin.pouget@gmail.com>]

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.
>
> --
> Pedro Alves

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

... I don't know if changing these numbers would be considered as a
backward incompatibility ... ?

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

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