JuicyPixels-blurhash-test: lost signal due to full pipe: 11

[juhp]

While running the 0.1.0.3 testsuite for Stackage Nightly, JuicyPixels-blurhash-test went into a infinite loop with lost signal due to full pipe: 11. Just a heads-up really, dunno if I was just unlucky or if it is reproducible.
This was with ghc-8.10.3 and stack-2.5.1.

[juhp]

src/Codec/Picture/Blurhash/Internal/Base83.hs:20:1: warning: [-Wdeprecations]
    Module ‘Data.ByteString.Lazy.Builder’ is deprecated:
      Use Data.ByteString.Builder instead
   |
20 | import qualified Data.ByteString.Lazy.Builder as BS
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

src/Codec/Picture/Blurhash/Internal/Encode.hs:21:1: warning: [-Wdeprecations]
    Module ‘Data.ByteString.Lazy.Builder’ is deprecated:
      Use Data.ByteString.Builder instead
   |
21 | import qualified Data.ByteString.Lazy.Builder as BS
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

src/Codec/Picture/Blurhash/Internal/Base83.hs:20:1: warning: [-Wdeprecations]
    Module ‘Data.ByteString.Lazy.Builder’ is deprecated:
      Use Data.ByteString.Builder instead

src/Codec/Picture/Blurhash/Internal/Encode.hs:21:1: warning: [-Wdeprecations]
    Module ‘Data.ByteString.Lazy.Builder’ is deprecated:
      Use Data.ByteString.Builder instead
Examples: 13  Tried: 13  Errors: 0  Failures: 0
test/Spec.hs
  testEncodeKnownHashPurePython: JuicyPixels-blurhash-test: lost signal due to full pipe: 11

JuicyPixels-blurhash-test: lost signal due to full pipe: 11

JuicyPixels-blurhash-test: lost signal due to full pipe: 11

JuicyPixels-blurhash-test: lost signal due to full pipe: 11

JuicyPixels-blurhash-test: lost signal due to full pipe: 11

JuicyPixels-blurhash-test: lost signal due to full pipe: 11

JuicyPixels-blurhash-test: lost signal due to full pipe: 11

JuicyPixels-blurhash-test: lost signal due to full pipe: 11

JuicyPixels-blurhash-test: lost signal due to full pipe: 11
:

[SamProtas]

Hi @juhp thanks for the report. I've noticed the same thing sporadically across GHC versions. It's not consistent.

Unfortunately my best guess at this point is a GHC runtime bug (I know, never good to jump to a problem with the language...) based on some existing bug reports I've found:

https://gitlab.haskell.org/ghc/ghc/-/issues/15544
https://issues.serokell.io/issue/TM-266

To the best of my knowledge I'm not using any low-level primitives or unsafe anything directly in this library. Given that, the reports above, and a lack of further leads, I'm not sure what else to think about these sporadic segfaults.

[juhp]

Yeah the latter issue seems similar