This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Python: fetch value when building gdb.Value object
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Paul Koning <paulkoning at comcast dot net>, pmuldoon at redhat dot com, gdb-patches at sourceware dot org
- Date: Tue, 04 Oct 2011 09:39:45 -0600
- Subject: Re: Python: fetch value when building gdb.Value object
- References: <36B29E9D-F2B3-446F-AF8A-97254A3AAEE2@comcast.net> <m3ipocii6a.fsf@redhat.com> <D9AC6973-91CF-42D4-AD81-0C4A41D3DD2A@comcast.net> <20111001090443.GA11227@host1.jankratochvil.net>
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Paul> If so, most of the Python code seems to be a candidate for
Paul> RETURN_MASK_ERROR.
Jan> In fact I do not know, it is a Python thing.
Jan> RETURN_MASK_ALL is right if returned PyExc_KeyboardInterrupt will really abort
Jan> any execution of Python code. It is probably so, as suggested by:
Jan> http://docs.python.org/library/exceptions.html#exceptions.KeyboardInterrupt
Jan> RETURN_MASK_ERROR is right otherwise, but only if it is safe to
Jan> longjmp out from a code called by Python. This may not be true.
Jan> Python may be C++ exceptions throwing safe but it cannot be safe
Jan> for the GDB longjmp exceptions. But this case would mean Python is
Jan> buggy for CTRL-C on its own so RETURN_MASK_ERROR probably is not
Jan> right.
I think the Python code in GDB should use RETURN_MASK_ALL in all cases.
The C-c case should be turned into PyExc_KeyboardInterrupt.
Other exceptions should either be ignored or turned into the appropriate
Python exception, depending on the situation.
Letting the C-c case longjmp over the Python implementation is bad, I
would imagine it will result in crashes. Ignoring it is also bad.
Paul> Probably related: I just tried an infinite Python loop and found
Paul> that control-C had no effect. I wonder if the Python interpreter
Paul> is setting up its own control-C trap (quite possibly -- that's a
Paul> Python exception after all) and we're losing it somewhere along
Paul> the lines.
Jan> Yes, this is the kind of bug from it, thanks for checking it.
I suspect we have to override Python's SIGINT handling.
I haven't investigated.
Jan> 2011-10-01 Jan Kratochvil <jan.kratochvil@redhat.com>
Jan> * python/py-value.c (valpy_getitem): New variable back_to. Register
Jan> xfree of field to it. Call do_cleanups for it. Use RETURN_MASK_ERROR
Jan> instead of RETURN_MASK_ALL.
This patch runs the cleanups too late. They have to be done before
GDB_PY_HANDLE_EXCEPTION, as that has an early return in it. Cleanest is
probably doing it all inside the TRY_CATCH.
Tom