#845 ^C handling within msys

[ericgm]

It is a well-known bug that SIGINT handlers in
Windows/MinGW executables are not called when the user
hits ^C, and the MinGW process exits abruptly.

In addition, it seems that when the executable starts
asynchronously others executables, the others are not
killed, as they seem to not receive SIGINT.

After having analyzed what was going on, it occurs that
the culprit is MSYS (CYGWIN) runtime that do not resend
CTRL_C_EVENT to the actual runtime of the executable.
It works when the runtime is MSYS, but not if it is
MinGW. The attached patch seems to fix the problem.

The basic idea is to send a CTRL_BREAK_EVENT if the
executable is not an MSYS one, but a MinGW one
(remember that sending CTRL_C_EVENT does not call
associated signal handler). The CTRL_BREAK_EVENT is
then handled by MinGW runtime which will emulate the
handling programmed by the executable. So, there is
one patch for mingw-runtime-3.1 and on set of patches
for msys-1.0.10, and it will required that MinGW
programs to be relinked with the new MinGW runtime.

Thanks,
Eric

[ericgm]

The patch for MSYS

[ericgm]

The patch for MinGW

[Danny Smith]

Logged In: YES
user_id=11494

I do not like the idea of making SIGINT handler the default
handler for CTRL_BREAK_EVENT's in mingw runtime.
Overriding a user-defined SIGBREAK handler is just wrong.

Danny.

[ericgm]

Logged In: YES
user_id=1320840

I completely agree with you, but CTRL_C_EVENT generated by
GenerateConsoleCtrlEvent() does not end up calling any
handler at all. So, the only way (I see for now) to get
SIGINT handler called in a MinGW program from MSYS is to
generate a CRTL_BREAK_EVENT.

In addition, since the handler is added before main() is
called, if a user wants to install a handler for a
BREAK_EVENT with SetConsoleCtrlHandler(), then his own one
will be called before the one installed, thus resulting in a
standard behavior from the users handler point of view (the
Windows documentation says handlers are called in
installation reverse order).

So, I would not say that the installed one overrides the
user's one, but rather that it overrides the default one
(which will nevertheless kill the application). The
installed one will be called only if the user's one returns
without having handled the BREAK_EVENT. But I must admit
that I trusted the Microsoft documentation, and did not test
by myself this behavior; I just spend a lot of time to find
the SIGINT handler problem and to implement a fix it to get
"GNU" applications working, with as little intrusion as
possible.

Of course, if you have anything else in mind (because I do
not know Windows system programming that well), please give
me your advice on how to have SIGINT MinGW handlers being
called from MSYS. You know better than me how frustrating it
is to be unable to stop a complex compilation running under
MSYS by hitting ^C...

Thanks in advance,
Eric

[Howard Chu]

Logged In: YES
user_id=330860
Originator: NO

I've submitted a new patch for this problem as tracker item 1624635. My patch has the advantage that it will work with most native Win32 apps even if they're not console apps, as long as they use the MSVC runtime.

(This revised patch may now be found attached to issue [#1783]).

[Earnie Boyd]

Cesar, what do you think about the status of this one?

[Jonas Thiem]

Would this fix gdb ctrl+c interrupt handling with proper application pause instead of ctrl+c just tearing down gdb itself?

If yes, would you mind to fix this after all those years? gdb working properly in crappy cmd.exe but not inside the MSYS shell seems a bit ridiculous.