Dangling ghc process when ctrl+C twice while "Running test..."

[asterite]

Description

When running ghci and passing --test something, if you press ctrl+C quickly twice then a dangling gch process will remain. The ghc process consumes 100% of the CPU.

Steps to reproduce

1. Download and extract my-project.zip into some directory. This is just a newly created project by following the steps described here, except that src/Lib.hs is modified to do putStrLn 30000 times without a loop (inlined). The reason for this long file is that it takes a noticeable time to compile (to simulate a big project).
2. cd into the directory and execute stack exec -- ghcid --test "Lib.someFunc"
3. When ghcid shows "Running test...` and before it starts running the program, hit ctrl+C twice, quickly. If done correctly to reproduce this, the word "Interrupted" shouldn't have appeared in the console.
4. Check that a dangling ghc process remains, consuming 100% of the CPU.

Diagnosis

I assume when ghcid shows "Running test..." and before it actually execute the program passed in --test, it compiles the program. If you hit ctrl+C once and wait you'll see "Interrupted" printed after a few milliseconds, and there will be no dangling ghc process. However, if you hit ctrl+C again before seeing "Interrupted", the program exists but a ghc process remains. My guess is that some clean up is missing at that point, but I'm not familiar with the code to further diagnose it and send a fix, but maybe this info can help.

This is probably related to #191, or another case of it, though this issue provides a way to consistently reproduce the problem.

[ndmitchell]

I assume you are on Windows, since otherwise the OS would take care of clean up for you.

Unfortunately without the OS playing ball, I'm a bit stuck. If the process refuses to terminate I could make ghcid also refuse to terminate, but that sucks. Also, with Cygwin and Mingw compatibility layers the behaviour changes again, so I'm not sure anyone has ever managed to get something working in all combinations.

[asterite]

Hi! Thanks for the reply. This is on Mac osx.

[asterite]

I forgot to ask: what OS are you on? And does it reproduce on that OS? Maybe it's only a mac osx thing.

[ndmitchell]

Weird. I thought Mac followed the same process owner pattern and thus leaking processes wasn't easy. I'm on Windows where I have no doubt this can reproduce.

[jwoudenberg]

Unfortunately without the OS playing ball, I'm a bit stuck. If the process refuses to terminate I could make ghcid also refuse to terminate, but that sucks.

I agree, but for me it sounds better than the current situation. Currently I don't know about the orphan processes until I open a process explorer because my computer got very hot and slow. If ghcid gets stuck on shutdown then I know something is going on (it could even write a message to the console explaining what its waiting for). Ideally I would then be able to force-kill ghcid to bring down ghcid itself and its child processes.

[ndmitchell]

@jwoudenberg fair point, hard to disagree... Perhaps printing out "Stuck while shutting ..." would give people the necessary clues.

[DanielG]

@ndmitchell you are aware of the GHC RTS's behaviour regarding SIGINT, right? https://gitlab.haskell.org/ghc/ghc/wikis/commentary/rts/signals#the-interrupt-signal

[...] If a second interrupt signal is received, then we terminate the process immediately; this is just in case the normal shutdown procedure failed or hung for some reason, the user is always able to stop the process with two control-C keystrokes.

[domenkozar]

This is crucial to fix for using ghcid for development purposes, otherwise you can end up with more then one development process, leading to weird behavior.

I'm using plain processes to start development and foreman will send a graceful shutdown event and then to a SIGKILL after 5 seconds.