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:44 AM, Tom Tromey wrote:
>>>>>> "Yit" == Khoo Yit Phang <khooyp@cs.umd.edu> writes:
>
> Yit> Doesn't throw_exception use a longjmp? Say that we're running inside
> Yit> Python's interpreter, and an Ctrl-C occurs, causing handle_sigint to
> Yit> be called. handle_sigint calls gdb_call_async_signal_handler
> Yit> (sigint_token, immediate_quit), which directly calls
> Yit> sigint_token-> proc which is async_request_quit, which in turn calls
> Yit> quit (), which calls throw_exception which calls longjmp to the
> Yit> nearest TRY_CATCH. At this point, we have no idea what the state of
> Yit> Python's interpreter is, and could well easily mangle something since
> Yit> the longjmp can occur at any point.
>
> This can only happen if immediate_quit is set. But, immediate_quit is
> used rarely in gdb. It is not really safe to use in most situations.
>
> We do have an issue that there are a few "bad" uses of immediate_quit.
> But we need to fix those anyhow, as SIGINTs delivered in those places
> can currently cause all kinds of issues.
>
> The code is kind of confusing because gdb_call_async_signal_handler
> conditionally does its work:
>
> if (immediate_p)
> call_async_signal_handler (handler);
> else
> mark_async_signal_handler (handler);
>
> immediate_p is just immediate_quit due to:
>
> gdb_call_async_signal_handler (sigint_token, immediate_quit);
Yes, that's my concern, if immediate_quit is set. As long as that's not the case, as you say, then it should be fine.
An aside: the immediate_quit++ in remote.c doesn't seem to be properly paired with immediate_quit--? The latter is only called when non_stop is not set.
Yit
July 30, 2012