#15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description:
{{{ $ cabal get cryptohash-sha256-0.11.101.0 $ cabal new-run -w ghc-8.6.1 --enable-test --allow-newer=cryptohash- sha256:base,*:stm,*:tasty,async:base test:test-sha256 -- -j 8 --quickcheck-tests 9999 }}}
Eventually the program will start spamming stderr with `test-sha256: lost signal due to full pipe: 11` repeatedly. This apparently only started with 8.6.1.
New description: {{{ $ cabal get cryptohash-sha256-0.11.101.0 $ cd cryptohash-sha256-0.11.101.0 $ cabal new-run -w ghc-8.6.1 --enable-test --allow- newer=*:base,*:stm,*:tasty test:test-sha256 -- -j 8 --quickcheck-tests 9999 }}} Eventually the program will start spamming stderr with `test-sha256: lost signal due to full pipe: 11` repeatedly. This apparently only started with 8.6.1. -- Comment (by sjakobi): Another variation I'm seeing when I add `--timeout 1s` is {{{ XL-vec inc: test-sha256: internal error: evacuate: strange closure type 0 (GHC version 8.6.0.20180810 for x86_64_unknown_linux) }}} Strangely I can't reproduce the bug when I try to run the apparently problematic testcase with `--pattern KATs.XL-vec.inc`. Also note that a similar issue has been reported for GHC-8.2.2 on 32-mips at https://github.com/haskell-hvr/cryptohash-sha256/issues/3. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15544#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler