Interrupting cabal-3.8.0.0.20220526 and master with ctrl+c makes it hang on windows

[jneira]

I am experiencing some weird behaviour interrupting cabal rc execution with ctrl+c in windows:
Doing a ctrl+c in the Configuring component for my package, with ghc-pkg subprocesses, hangs the program with rc1

I cant reproduce with 3.6.0.0

[Mikolaj]

Possibly introduced by #7921, even though it says "on unix systems".

could you try building cabal with process 1.6.14 or later?
building with GHC 9.2 may include that by default
I don't remember which GHC gitlab CI uses and so which which GHC the cabal binaries have been built
nor which GHC ghcup uses to build RC1 cabal
anyway, that's a long shot, process < 1.6.14 had some faults, but possibly not as grave as hanging

[jneira]

cabal in gitlab is built with ghc-8.10.7 iirc

[jneira]

I checked that pr and I did not get any hang, tests could be wrong though
#7921 (comment)

And a confirmation of the bug by another windows user would be great, i will try again with other projects myself

[Mikolaj]

Yes, dear Windows users, please reproduce.

[robx]

The "on unix systems" is just to say that the change isn't expected to necessarily fix things on Windows. It definitely does touch Windows too, and there's a decent chance of something like this slipping through...

One factor that might come into play is that GHC has two different Windows I/O managers, which behave differently with respect to types and sub-processes, see e.g. here haskell/process#235. It might be worth checking if that is involved here. (I don't really know which GHC version uses which I/O manager by default and/or whether they're switchable...)

[jneira]

in my test I used ghc-8.10.7, which did not have the new io manager
cabal release itself has been built with ghc-8.10.7
afair that new io manager is still not the default in ghc-9.2

[Mikolaj]

FYI: I'm getting "waitForProcess: does not exist (No child process)" when interrupting long running cabal test, on an ancient Ubuntu. I don't remember getting that before 3.8, but my memory is unreliable. However, this is obviously better than accumulating half-dead processes.

We still have to decide whether to revert for 3.8, e.g., waiting until the new GHC IO fixes the problem or until somebody fixes it differently or until enough Windows users can't reproduce it and so a fluke on a single Windows system is a valid suspicion.

An argument for not reverting is that we only got one report of the problem for the pre-release. However, not many Windows users are early adopters so that may be a sampling bias.