Cabal: Cabal requires tighter bounds on process on windows.

[AndreasPK]

To my knowledge all but the latest version of process (1.6.10.0) run the risk of producing segfaults on windows.

To Reproduce

I can reproduce this reliably by building cabal-install with ghc-8.10.1.

The resulting cabal binary will then segfault on most operations.

Expected behavior
A clear and concise description of what you expected to happen.

System information

• Windows
• Cabal-head, ghc-8.10.1

[phadej]

Is 1.6.10.0 required, the 1.6.9.0 bundled with GHC-8.8.4 is not enough?

[AndreasPK]

I'm not sure. @Mistuke do you know if the fix is also in 1.6.9?

[jneira]

Wow, i did not know that executables compiled against process lib versions with the bug were causing segfault at runtime.
I thought that was ghc itself that was throwing the segfaults when compiling packages. So thery should be solved using a proper ghc version (ghc-8.8.4 or ghc-8.10.1 ) indpendently of the build tool (cabal or stack) and the ghc used to compile that build tool.

If it is not the case it would be great to fix it in cabal asap. 👍
I have an issue with segfaults using ghc-8.8.4 and cabal and maybe a cabal exec compiled against a newer process would fix them. I'll try to test that.

[Mistuke]

The fix is in 1.6.9 https://github.com/haskell/process/blob/master/changelog.md#169-may-2020 1.6.10 has an unrelated fix for pipes.

@jneira GHC 8.10.1 is broken as well. 8.10.1 was released with same process as 8.8.3.

[Mistuke]

That said, Cabal currently deals with this with a compile time check https://github.com/haskell/cabal/blob/95c5e40116e178b6f003c9d464a49ea16268e2df/Cabal/src/Distribution/Compat/Process.hs#L33 but it's checking for 1.6.8 since we thought that fixed the issue.

Without process jobs cabal would be intermittently unreliable but still work. We thought at the time it would be a nicer trade-off.

[jneira]

@mistuke

GHC 8.10.1 is broken as well. 8.10.1 was released with same process as 8.8.3.

Thanks for the clarification.

That said, Cabal currently deals with this with a compile time check

Then maybe we should update the process version in the cpp check to 1.6.9, instead change process bounds (that maybe would break building cabal with older ghc versions?)

[AndreasPK]

There is this comment surrounding the CPP:

-- | Enable process jobs to ensure accurate determination of process completion
-- in the presence of @exec(3)@ on Windows.
--
-- Unfortunately the process job support is badly broken in @process@ releases
-- prior to 1.6.9, so we disable it in these versions, despite the fact that
-- this means we may see sporatic build failures without jobs.

Wouldn't it be better to bump the required process version to avoid the "sporadic build failures without jobs"? As I understand it cabal built against an older process version will be broken one way or another. Updated CPP or not.

This would mean Cabal on windows requires at least GHC-7.10.3 to be built. I would take that over random sporadic build failures any time.

[jneira]

This would mean Cabal on windows requires at least GHC-7.10.3 to be built. I would take that over random sporadic build failures any time.

It is a quite old ghc version so if it is the unique additional constraint it would worth the version bump imo.

[AndreasPK]

For completeness here is the error that I get currently, that is without any patch for mitigation applied and trying to use a cabal linked against a broken process version:

Andi@Horzube MINGW64 ~/cabal-head/cabal-install
$ cabal build

Access violation in generated code when writing 0x0

 Attempting to reconstruct a stack trace...

   Frame        Code address
 * 0x2adda90    0x1df0ee6 C:\Users\Andi\AppData\Roaming\cabal\bin\cabal.exe+0x19f0ee6
 * 0x2adda98    0x1bbb5e9 C:\Users\Andi\AppData\Roaming\cabal\bin\cabal.exe+0x17bb5e9
 * 0x2addaa0    0x3
 * 0x2addaa8    0x4cca481
 * 0x2addab0    0x2186420 C:\Users\Andi\AppData\Roaming\cabal\bin\cabal.exe+0x1d86420
 * 0x2addab8    0x4cb7f30

[phadej]

@AndreasPK this is now fixed with your patch, isn't it?

[AndreasPK]

The seg fault is fixed yes.