Re: [GHC] #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c

5 Mar 2017

      #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c
-------------------------------+----------------------------------------
        Reporter:  vanto       |                Owner:  (none)
            Type:  bug         |               Status:  upstream
        Priority:  normal      |            Milestone:
       Component:  GHCi        |              Version:  8.0.2
      Resolution:              |             Keywords:
Operating System:  Windows     |         Architecture:  Unknown/Multiple
 Type of failure:  GHCi crash  |            Test Case:
      Blocked By:              |             Blocking:
 Related Tickets:              |  Differential Rev(s):
       Wiki Page:              |
-------------------------------+----------------------------------------
Changes (by Phyx-):

 * status:  new => upstream
 * architecture:  x86 => Unknown/Multiple

Comment:

 Thanks for the report, this seems to be an issue with the mingw-w64
 runtime. I haven't narrowed it down yet, but essentially something seems
 to be eating the events and it never reaches ghci.

 `CtrlHandler` is never called.

 The following example shows the issue. It works when compiled using the
 Microsoft compiler but doesn't with mingw-w64's GHC.

 {{{
 #include <windows.h>
 #include <stdio.h>

 BOOL CtrlHandler( DWORD fdwCtrlType )
 {
   switch( fdwCtrlType )
   {
     // Handle the CTRL-C signal.
     case CTRL_C_EVENT:
       printf( "Ctrl-C event\n\n" );
       Beep( 750, 300 );
       return( TRUE );

     // CTRL-CLOSE: confirm that the user wants to exit.
     case CTRL_CLOSE_EVENT:
       Beep( 600, 200 );
       printf( "Ctrl-Close event\n\n" );
       return( TRUE );

     // Pass other signals to the next handler.
     case CTRL_BREAK_EVENT:
       Beep( 900, 200 );
       printf( "Ctrl-Break event\n\n" );
       return FALSE;

     case CTRL_LOGOFF_EVENT:
       Beep( 1000, 200 );
       printf( "Ctrl-Logoff event\n\n" );
       return FALSE;

     case CTRL_SHUTDOWN_EVENT:
       Beep( 750, 500 );
       printf( "Ctrl-Shutdown event\n\n" );
       return FALSE;

     default:
       return FALSE;
   }
 }

 int main( void )
 {
   if( SetConsoleCtrlHandler( (PHANDLER_ROUTINE) CtrlHandler, TRUE ) )
   {
     printf( "\nThe Control Handler is installed.\n" );
     printf( "\n -- Now try pressing Ctrl+C or Ctrl+Break, or" );
     printf( "\n    try logging off or closing the console...\n" );
     printf( "\n(...waiting in a loop for events...)\n\n" );

     while( 1 ){ }
   }
   else
   {
     printf( "\nERROR: Could not set control handler");
     return 1;
   }
 return 0;
 }
 }}}

 This also doesn't work in an msys2 console, even though it appears to. In
 the case of msys2 bash is disabling `ENABLE_PROCESSED_INPUT` so that
 `CTRL+C` is not processed by the system and is reported as a input stream.
 Bash is then just terminating the process by force.

 In the case of GHCi, something does clearly happen with the runtime since
 it suddenly starts allocating a large amount of memory and enters some
 kind of deadlock. So there are two separate issues here.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13359#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler