This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/4]: Handle SIGINT under Python by raising KeyboardInterrupt
Hi,
On Jul 30, 2012, at 11:36 AM, Khoo Yit Phang wrote:
>
> On Jul 30, 2012, at 11:10 AM, Tom Tromey wrote:
>
>>>>>>> "Yit" == Khoo Yit Phang <khooyp@cs.umd.edu> writes:
>>
>> Yit> This looks like it might work, I'll give it a go and get back to
>> Yit> you. The only issue I see right now is if immediate_quit is set, it
>> Yit> could leave Python in a bad state (among other issues). Perhaps make
>> Yit> immediate_quit an argument of check_quit_flag?
>>
>> I don't think it can cause problems.
>>
>> handle_sigint calls set_quit_flag. Then it (indirectly) calls
>> async_request_quit.
>>
>> async_request_quit checks immediate_quit and, if it is set, calls quit.
>>
>> Eventually quit calls throw_exception, which clears the quit flag.
>
> Doesn't throw_exception use a longjmp? Say that we're running inside Python's interpreter, and an Ctrl-C occurs, causing handle_sigint to be called. handle_sigint calls gdb_call_async_signal_handler (sigint_token, immediate_quit), which directly calls sigint_token->proc which is async_request_quit, which in turn calls quit (), which calls throw_exception which calls longjmp to the nearest TRY_CATCH. At this point, we have no idea what the state of Python's interpreter is, and could well easily mangle something since the longjmp can occur at any point.
I mean, when immediate_quit is set, gdb_call_async_signal_handler (sigint_token, immediate_quit) immediately calls sigint_token->proc that leads to the quit, throw_exception and longjmp. It does not wait until some other time.
Yit
July 30, 2012