Fix mysterious hanging issue

[newhoggy]

This is more of a work-around, but moving the check to a new Hedgehog.Internal.Check module, then copying checkNamed and checkRegion functions to the same module solves a mysterious hanging issue when using tasty and hedgehog together.

The hang is verified to no longer happen with these changes by running the test in this branch:

https://github.com/newhoggy/tasty-hang/tree/newhoggy/fix-mysterious-hanging-issue

To run test, run:

cat tasty-hang-bad.sh | parallel

then use this to watch for a hang:

watch ls -la stdout-*.log stderr-*.log

Resolves #547

[carbolymer]

You forgot to remove it from hedgehog/src/Hedgehog/Internal/Runner.hs

[newhoggy]

I cannot remove those because they are needed by other functions in the Runner module.

[moodmosaic]

Thanks, @newhoggy. Good catch with setRegion vs openRegion. If the fix is in how checkNamed and checkRegion handle region output, was the new module strictly needed?

[Bodigrim]

Good catch with setRegion vs openRegion. If the fix is in how checkNamed and checkRegion handle region output, was the new module strictly needed?

I cannot spot any difference with regards to checkNamed / checkRegion?.. It seems like just copying functions to a separate module solved the problem?..

[moodmosaic]

@Bodigrim, the fix is the setRegion vs openRegion change: keep setRegion for Running and OK, and only use openRegion for Shrinking, Failed, and GaveUp. That avoids the unbounded region growth and console contention with Tasty that caused the hang. -- The split is optional and perhaps should be done in a follow up PR.

[luite]

It looks like this was caused by a GHC bug causing threads to get stuck when multiple threads would enter a CAF closure in quick succession.

You can try my proposed fix here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14734

If this is indeed the correct fix for the problem, we'll likely backport it to 9.10 and 9.12

[moodmosaic]

Wow! Thank you @luite for this incredible insight and for tracking this down to a potential GHC bug!

It seems I was mistaken earlier. Based on your analysis, the key change is the module split itself, which serves as a structural workaround for the GHC bug related to CAF contention, rather than any specific logic change in setRegion/openRegion as I had previously thought.

Given that the permanent solution lies upstream in GHC, I propose the following plan:

1. Put this PR on hold and monitor the GHC merge request https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14734.
2. If the fix is merged and backported to relevant versions (e.g., 9.10, 9.12), we can close this PR with a reference to the upstream fix.
3. If the GHC fix stalls or is not backported, we can revisit merging this PR as an effective workaround for our users.

Many thanks to @newhoggy for discovering a workaround that not only unblocked users but also helped lead to the discovery of this underlying GHC issue.