Re: [RFC] control-c handling on Windows...

[Christopher Faylor <cgf-use-the-mailinglist-please at sourceware dot org>]

On Wed, May 07, 2008 at 01:56:11PM -0700, Joel Brobecker wrote:
>Hello,
>
>We noticed the following anomaly when trying to interrupt the inferior
>with a control-c event:
>
>(gdb) run
>Starting program: C:\[...]/always.exe
>[New thread 6772.0xadc]
>Hello world: 1
>Hello world: 2
>[New thread 6772.0x13fc]
>[Switching to thread 6772.0x13fc]
>Quit (expect signal SIGINT when the program is resumed)
>(gdb)
>
>The debugger stopped but doesn't show the usual "Program received
>SIGINT [...]" message. It almost looks like the debugger stopped
>because of the new thread.
>
>Also, the "Quit (expect signal SIGINT when the program is resumed)"
>message is indeed right. When I do a "continue", I immediately get
>the SIGINT:
>
>    (gdb) c
>    Continuing.
>    Hello world: 3
>    Program received signal SIGINT, Interrupt.
>    0x7c87534d in KERNEL32!GetConsoleCharType ()
>       from C:\WINDOWS\system32\kernel32.dll
>    (gdb)
>
>In fact, what happened was that GDB received a SIGINT event,
>and as such set the quit_flag. At the same time, the inferior
>received the control-c event as well, and therefore created
>a new thread to handle it. That new thread generated an event
>intercepted by GDB; after GDB updated its thread list, it tried
>to resume the execution. However, there is a QUIT at the very
>beginning of resume which, because of quit_flag being set,
>aborted the resume action. This is why GDB stopped the first
>time instead of resuming until we get the control-c exception
>event.

>I think this is happening because of a change that was made a year
>ago which adds a call to target_terminal_ours at the beginning of
>win32_wait().  As a result, the SIGINT handler gets reactivated while
>the inferior is running.  This change was made because TUI apparently
>does some output while the terminal process group is set to the inferior
>process.

Thanks for the analysis.  I've talked to Corinna about this since she
was responsible for the original patch in question.  I think her patch
still makes sense so I guess your change is required although I can't
shake the feeling that there is some CreateProcess setting that we're
missing to deal with this behavior.

But, if your patch fixes the problem I'm ok with checking it in.

cgf