From: SourceForge.net <no...@so...> - 2005-10-20 13:36:08
|
Bugs item #1333217, was opened at 2005-10-20 15:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1333217&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: msys Group: Known bugs Status: Open Resolution: None Priority: 5 Submitted By: ericgm (ericgm) Assigned to: Earnie Boyd (earnie) Summary: ^C handling within msys Initial Comment: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1333217&group_id=2435 |
From: SourceForge.net <no...@so...> - 2005-10-21 04:56:28
|
Bugs item #1333217, was opened at 2005-10-21 02:35 Message generated for change (Comment added) made by dannysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1333217&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: msys Group: Known bugs Status: Open Resolution: None Priority: 5 Submitted By: ericgm (ericgm) Assigned to: Earnie Boyd (earnie) Summary: ^C handling within msys Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2005-10-21 17:56 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1333217&group_id=2435 |
From: SourceForge.net <no...@so...> - 2005-10-21 21:38:26
|
Bugs item #1333217, was opened at 2005-10-20 15:35 Message generated for change (Comment added) made by ericgm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1333217&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: msys Group: Known bugs Status: Open Resolution: None Priority: 5 Submitted By: ericgm (ericgm) Assigned to: Earnie Boyd (earnie) Summary: ^C handling within msys Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: ericgm (ericgm) Date: 2005-10-21 23:38 Message: 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 ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2005-10-21 06:56 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1333217&group_id=2435 |
From: SourceForge.net <no...@so...> - 2006-12-29 22:30:52
|
Bugs item #1333217, was opened at 2005-10-20 06:35 Message generated for change (Comment added) made by highlandsun You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1333217&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: msys Group: Known bugs Status: Open Resolution: None Priority: 5 Private: No Submitted By: ericgm (ericgm) Assigned to: Earnie Boyd (earnie) Summary: ^C handling within msys Initial Comment: 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 ---------------------------------------------------------------------- Comment By: Howard Chu (highlandsun) Date: 2006-12-29 14:30 Message: 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. ---------------------------------------------------------------------- Comment By: ericgm (ericgm) Date: 2005-10-21 14:38 Message: 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 ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2005-10-20 21:56 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1333217&group_id=2435 |