Test suite hangs with ghc 8.4 (apparently due to hspec-2.5.0)

[DanBurton]

The last thing printed is:

Control.Exception.Enclosed
  catchAny
    catches exceptions thrown from the inside
    doesn't catch exceptions thrown from the outside
    doesn't catch exceptions lazily thrown in its pure result
  catchDeep
    catches exceptions thrown from the inside
    catches exceptions thrown from the outside
    catches exceptions lazily thrown in its pure result
  tryAny
    catches exceptions thrown from the inside
    doesn't catch exceptions thrown from the outside
    doesn't catch exceptions lazily thrown in its pure result

The next test is:

enclosed-exceptions/test/main.hs

Line 85 in ba1b356

it "isn't fooled by BlockedIndefinitelyOnMVar" $ do

which suggests to me that something is going on with the "blocked indefinitely" behavior. Possibly a GHC regression?

[snoyberg]

I don't have much time to look at this right now, but a quick test on my machine did not reproduce this. I was using nightly-2018-03-14.

[DanBurton]

@snoyberg that was a fortunate observation. I too am able to reproduce a passing test suite with nightly-2018-03-14. However, I am also able to reproduce the error with nightly-2018-03-17. This helps us isolate the cause, which is apparently hspec-2.5.0.

stack unpack enclosed-exceptions-1.0.2 && cd enclosed-exceptions-1.0.2
edit stack.yaml # try the various stack.yaml files
stack test

# stack.yaml
# requires stack upgrade --git
# test suite passes
resolver: nightly-2018-03-14

# stack.yaml
# requires stack upgrade --git
# test suite hangs
resolver: nightly-2018-03-14
extra-deps:
- hspec-2.5.0
- hspec-core-2.5.0
- hspec-discover-2.5.0

# stack.yaml
# test suite hangs
resolver: nightly-2018-03-17

# stack.yaml
# test suite passes
resolver: nightly-2018-03-17
extra-deps:
- hspec-2.4.8
- hspec-core-2.4.8
- hspec-discover-2.4.8

(For those who don't want to bother with stack upgrade --git, you can simply refer to the last 2 examples, which are sufficient to illustrate that hspec-2.5.0 is the cause of the discrepancy here.)

[snoyberg]

This may be insurmountable, and the only result may be to disable the test. It appears that both the test case itself, and the hspec main thread, are blocked on MVars here, which is to be expected I suppose (depending on how hspec is implemented). GHC's runtime system doesn't know which thread to kill first, and so kills both of them. This is a common shortcoming with no obvious workaround. CC @jcristovao.

[DanBurton]

How unfortunate. It seems like there should be some sort of workaround, and that workaround should be used by the tryAny function. Perhaps some sort of GHC primitive that says "I'm spawning a thread, but if both of us get blocked indefinitely, kill that one first." Would it make sense to make a GHC bug report or feature request for this issue?

In any case, I agree that with GHC as it is currently, there is probably nothing for enclosed-exceptions to do but disable the test case until something changes.

[snoyberg]

I don't think there's anything to be done at the GHC level. See this discussion on the async package: simonmar/async#14.

[ElvishJerricco]

Should this test simply be removed then, at least when building with 8.4? Nixpkgs always runs tests, so this obviously breaks with the 8.4 haskell package set. Not a big deal, since we can just disable the tests on this package, but it'd be nice if we didn't have to do that for future versions.

[peti]

We see this test failure in current Nixpkgs, too. We can produce the issue reliably, the test suite always fails (building in an LTS-12.0 environment).

[snoyberg]

@jcristovao do you have input on this, as this is your package? If you want, I'll make a call here, which would be: PR to remove the test would be acceptable.

[jcristovao]

Hey @snoyberg, feel free to make any changes that you deem necessary - I have been doing very little haskell nowadays, and I fully trust your judgement :)

[snoyberg]

Alright, have a look at #13. If/when CI passes, I'll merge and release to Hackage.