Re: [PATCH 2/4]: Handle SIGINT under Python by raising KeyboardInterrupt

[Khoo Yit Phang <khooyp at cs dot umd dot edu>]

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