This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC][Python] gdbpy_frame_stop_reason_string bug
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