`feedback -- cabal test` fails

[Bodigrim]

feedback -- cabal test fails pretty much on any project with

16:07:06 starting   cabal test
Resolving dependencies...
Build profile: -w ghc-9.2.2 -O1
In order, the following will be built (use -v for more details):
 - zlib-0.6.2.3 (lib) (first run)
 - zlib-0.6.2.3 (test:tests) (first run)
cabal: Failed to build zlib-0.6.2.3 (which is required by test:tests from
zlib-0.6.2.3). The failure occurred during the configure step. The exception
was:
/Users/andrew/.ghcup/bin/cabal-3.6.2.0: createProcess: dup2: invalid argument
(Bad file descriptor)

16:07:08 exited:    failed: 1
16:07:08 took       2.07s

Running cabal test itself succeeds without surprises. I'm on Mac.

Any idea what's wrong here? Happy to redirect this to cabal team, if you think the issue is on their side.

[NorfairKing]

Huh, I have no idea. This will require some digging. I have seen this error before but don't remember where or why. Please let me know if you happen to find it!

[Bodigrim]

@jneira @Mikolaj @gbaz any ideas what's going on with cabal here?

[Mikolaj]

I don't know, but it would seem that cabal test redirects and/or duplicates stdin and/or stdout, creates new processes using those and that there is a clash with feedback over that? I guess the new processes are test jobs and the redirects are to capture test output to files.

[NorfairKing]

https://github.com/NorfairKing/feedback/blob/8cc1a0efaaad034ed28a346742216a4f82d74d01/feedback/src/Feedback/Common/Process.hs#L59-L61

Looks like this TODO became relevant :D

[Bodigrim]

@Mikolaj could Cabal possibly catch the error and report it gracefully instead of aborting with an internal error?

[Mikolaj]

@Bodigrim: that's a good question. Would cabal detect that stdin/stdout/stderr are not in correct state before calling createProcess? Or would cabal intercept any exception from createProcess and hint about possibly stdin/stdout/stderr being manipulated by another program and then dump the internal createProcess exception? Or anything else?

[Bodigrim]

@Mikolaj From my perspective, anything which gives a location in Haskell code will do, because "createProcess: dup2: invalid argument (Bad file descriptor)" does not hint at all which createProcess is at fault. Like, catching exceptions after any createProcess and wrapping them into "hey, Cabal called createProcess at Foo.hs:42:1, but it failed with this mumbo-jumbo".

[Mikolaj]

Oh, I only now noticed there is no line number. Why so? Perhaps https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/callstack.html could be used to ensure there is? I don't remember: should HasCallStack be added in cabal or in process for it to work? I guess, in cabal, because you'd like to know which call to process caused the error. So would adding HasCallStack to every function in cabal that calls createProcess solve the problem? If you think so, could you open a cabal ticket?

[Bodigrim]

The issue was caused by https://github.com/haskell/process/pull/250. Building cabal against process-1.6.15.0 fixes it. @Mikolaj I think Cabal might want to pin process >= 1.6.15 instead of process >= 1.6.14.

[NorfairKing]

@Bodigrim Great digging!