#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
#include
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
