Opened 3 years ago

Last modified 3 years ago

#13359 new bug

GHCi crash in a standard Windows console (cmd.exe) after Control-c

Reported by: vanto Owned by:
Priority: normal Milestone:
Component: GHCi Version: 8.0.2
Keywords: Cc:
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: GHCi crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

When you press and hold Ctrl-c, after a few seconds, sometimes > 60 sec, GHCi crash and we can read a message on the screen (of the console) who says:

ghc.exe : failed to create OS thread

On the task manager we can read:

ghc memory : 36920K

initially, then the memory grows about

ghc memory : 43480K

and stay until the crash. I repeated it several times. With Linux if you repeat this, GHCi do not crash. Idem with only the Windows console. Hope this help!

Change History (4)

comment:1 Changed 3 years ago by Phyx-

Architecture: x86Unknown/Multiple
Status: newupstream

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.

comment:2 Changed 3 years ago by Phyx-

Status: upstreamnew

It seems that the issue is not GCC, but the trigger does still not fire in GHC for some reason. Need to investigate further.

comment:3 Changed 3 years ago by Phyx-

Differential Rev(s): Phab:D3292
Status: newpatch

comment:4 Changed 3 years ago by Phyx-

Differential Rev(s): Phab:D3292
Status: patchnew

Accidentally assigned patch here.

Note: See TracTickets for help on using tickets.