Re: What happened in gdb between handle_sigint and async_request_quit?

["Amker.Cheng" <amker dot cheng at gmail dot com>]

Hi Joel:
  Thanks for the detailed explanation, It's very helpful.
The patch you mentioned was applied after the release of version 6.8,
I was wondering then why GDB stops twice at a great probability when
one CTRL+C being hit.

But one more question, where GDB blocks CTRL+C handler? I was thinking
that the handler
"handle_sigint" is always registered during waiting for inferior's event.

Thanks a lot.
Regards.

On Sat, Feb 7, 2009 at 12:42 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> both of GDB and Debuggee will get the event. Windows will report DBG_CONTROL_C
>> exception to GDB, which was turned into TARGET_SIGNAL_INT in GDB.
>> According to MSDN, this is the First Chance Exception!
>
> The situation on Windows is different from the situation on Unix.
> On Unix, we give the terminal back to the inferior while the inferior
> is running. So, when a user presses Ctrl-c, only the inferior gets
> the signal.  This signal triggers a debug event to GDB and suspends
> the inferior, and GDB treats this signal as it would treat any other
> signal.  On Windows, things are a little trickier, because the inferior
> and GDB might be running in the same console.  This means that, when
> the user presses Ctrl-c, then *both* GDB and the inferior get the
> associated signal. But we don't actually want GDB to receive the signal,
> so we simply temporarily ignore all Ctrl-C signals in GDB while the
> inferior is waiting:
>
>      /* Ignore CTRL+C signals while waiting for a debug event.
>         FIXME: brobecker/2008-05-20: When the user presses CTRL+C while
>         the inferior is running, both the inferior and GDB receive the
>         associated signal.  If the inferior receives the signal first
>         and the delay until GDB receives that signal is sufficiently long,
>         GDB can sometimes receive the SIGINT after we have unblocked
>         the CTRL+C handler.  This would lead to the debugger to stop
>         prematurely while handling the new-thread event that comes
>         with the handling of the SIGINT inside the inferior, and then
>         stop again immediately when the user tries to resume the execution
>         in the inferior.  This is a classic race, and it would be nice
>         to find a better solution to that problem.  But in the meantime,
>         the current approach already greatly mitigate this issue.  */
>      SetConsoleCtrlHandler (NULL, TRUE);
>      retval = get_windows_debug_event (pid, ourstatus);
>      SetConsoleCtrlHandler (NULL, FALSE);
>
> The code above assumes that the inferior and GDB are running in
> the same console, which is not always the case. Currently, when
> this is the case, the only way to interrupt your program is by
> pressing Ctrl-c in the console where your program is running.
> There is  patch pending that enhances GDB to handle the case when
> the inferior is running in a separate console.
>
> --
> Joel
>