Nondeterministic Failure on aarch64 with -jn, n > 1

Travis Whitaker pi.boy.travis at
Fri Jul 27 08:13:33 UTC 2018

Hello GHC Devs,

It seems to me that GHC is rather broken on aarch64, at least since 8.2.1
(and at least on the machines I have access to). I first noticed this issue
with Nixpkgs (, so to check
that this isn't some Nixpkgs idiosyncrasy I went ahead and built my own GHC
8.4.3 for aarch64 (there's no binary release at to try, but perhaps
I've missed something.

It seems the only Nix idiosyncrasy was passing "--ghc-option=-j${cores}" to
"./Setup.hs configure". The issue is triggered by using '-jn' for any n
greater than one when building any non-trivial package, but I've found
hscolour1.24.4 reproduces it very reliably (perhaps because there are
opportunities for parallelism early in its module dependency graph?). GHC
very often (although not always) will fail with one of:

- Segmentation fault.
- Bus fault
- <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:
Aborted (core dumped)

The fix, excruciating as it may be on already slow arm machines, is to use
'-j1'. This issue seems present on each GHC release since 8.2.1 (although I
haven't tried HEAD yet). I haven't noticed any issues with any other
concurrent Haskell programs on aarch64.

There are some umbrella bugs for aarch64 in Trac, so I wanted to ask here
before filing a ticket. Has anyone else noticed this behavior on aarch64?
What's more, are there any tips for using GDB to hunt down synchronization
issues in GHC?

Thanks for all your hard work!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list