Nondeterministic Failure on aarch64 with -jn, n > 1
GHC releases 8.2.1 through 8.4.3 exhibit various crashes when invoked with '-jn' where n \> 1. GHCHQ's binary releases have this behavior, as well as GHCs I've cross-built on my own.
In order to reproduce this issue there must be some parallelism in the module dependency graph; I've attached a test package for easily reproducing this. Use of deriving in the test modules isn't necessary to trigger this; it merely gives the compiler some work to do. The 'hscolour' package also triggers this issue reliably.
To trigger the bad behavior, simply run:
ghc --make -jn Main.hs -o test
with n \> 1 in the test-package. Running this repeatedly (removing .hi and .o files in between runs, of course), I've observed these outcomes with varying frequencies:
- Segmentation fault.
- Bus fault.
- Compiler process sleeps indefinitely.
-
```
<no location info>: error:
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for aarch64-unknown-linux):
Binary.UserData: no put_binding_name
```
-
```
ghc: internal error: MUT_VAR_CLEAN object entered!
(GHC version 8.4.3 for aarch64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
- And most strangely:
```
A.hs:3:1: error:
• Kind signature on data type declaration has non-* return kind *
• In the data declaration for ‘A’
|
3 | data A = A
| ^^^^^^^^^^...
```
I have not noticed issues with any other concurrent Haskell programs on aarch64. I'm using the NVIDIA Jetson TX2 for these tests. I have not yet tried GHC 8.0.x, 8.6.x, or HEAD. I'm having trouble reproducing this in GDB; I'll report back when I've got that working.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Nondeterministic Failure on aarch64 with -jn, n > 1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC releases 8.2.1 through 8.4.3 exhibit various crashes when invoked with '-jn' where n > 1. GHCHQ's binary releases have this behavior, as well as GHCs I've cross-built on my own.\r\n\r\nIn order to reproduce this issue there must be some parallelism in the module dependency graph; I've attached a test package for easily reproducing this. Use of deriving in the test modules isn't necessary to trigger this; it merely gives the compiler some work to do. The 'hscolour' package also triggers this issue reliably.\r\n\r\nTo trigger the bad behavior, simply run:\r\n\r\nghc --make -jn Main.hs -o test\r\n\r\nwith n > 1 in the test-package. Running this repeatedly (removing .hi and .o files in between runs, of course), I've observed these outcomes with varying frequencies:\r\n\r\n- Segmentation fault.\r\n- Bus fault.\r\n- Compiler process sleeps indefinitely.\r\n- \r\n{{{\r\n<no location info>: error:\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.3 for aarch64-unknown-linux):\r\n Binary.UserData: no put_binding_name\r\n}}}\r\n\r\n- \r\n{{{\r\n ghc: internal error: MUT_VAR_CLEAN object entered!\r\n (GHC version 8.4.3 for aarch64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n Aborted (core dumped)\r\n}}}\r\n- And most strangely:\r\n{{{\r\nA.hs:3:1: error:\r\n • Kind signature on data type declaration has non-* return kind *\r\n • In the data declaration for ‘A’\r\n |\r\n3 | data A = A\r\n | ^^^^^^^^^^...\r\n}}}\r\n\r\nI have not noticed issues with any other concurrent Haskell programs on aarch64. I'm using the NVIDIA Jetson TX2 for these tests. I have not yet tried GHC 8.0.x, 8.6.x, or HEAD. I'm having trouble reproducing this in GDB; I'll report back when I've got that working.","type_of_failure":"OtherFailure","blocking":[]} -->
issue