Opened 4 years ago

Last modified 3 years ago

#10469 new bug

ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type

Reported by: joeyhess Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.10.1
Keywords: Cc: erikd
Operating System: Linux Architecture: arm
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


ghc: internal error: scavenge: unimplemented/strange closure type 0 @ 0xac103240

(GHC version 7.10.1 for arm_unknown_linux) Please report this as a GHC bug:


I can consistently get either this crash, or a segfault from ghc, building git-annex on an arm system. Seems about 50/50. In either case, it crashes either before ghc has printed out any "Compiling" lines, or within the first 1 or 2 files compiled.

I got lucky and found out a way to avoid the crash.. cabal was passing -j2 to ghc. If I remove the -j2, the build proceeds without a crash.

The hardware is a CubieTruck arm board, with 2 gb of ram, and 1 cpu core, running Debian armel unstable, with kernel 3.4.103.

I was able to use cabal to install the entire dependencies of git-annex, all the way up to yesod, which takes hours on this hardware, and all that built ok.. so I think the hardware is pretty stable, but still cannot really rule out a hardware problem.

Happy to debug further, although this machine is a bit resource constrained to do things like building ghc on it.

ghc 7.8.4 and 7.10.1 both crash the same way.

Change History (6)

comment:1 Changed 4 years ago by rwbarton

Does your generated includes/ghcautoconf.h set arm_HOST_ARCH_PRE_ARMv6 and/or arm_HOST_ARCH_PRE_ARMv7? (I see your board has an ARMv7 processor, but maybe the Debian toolchain is set up to target an earlier architecture by default.)

comment:2 Changed 3 years ago by erikd

Cc: erikd added

Good news is that 7.10.2 is much better on Arm than 7.10.1 or 7.8.4. I also expect 7.10.3 and 8.0.1 to be better again.

During debugging #10375 I found two serious problem with the interaction between Arm and Thumb2 code. Ghc 7.10.3 and 8.0 will both force all code to be armv6-unknown-linux-gnueabihf which should fix a lot of the problems like this one.

comment:3 Changed 3 years ago by joeyhess

Thanks for looking into this erik. But would forcing hf mean ghc can't be used on regular eabi arm systems? Debian is still targeting eabi in its armel architecture.

comment:4 Changed 3 years ago by erikd

Ah ok. The patch currently forces armv6-unknown-linux-gnueabihf, but the hf is not the important bit. The important bit is to make sure the C code and Haskell code both get compiled to Arm instructions and not Thumb2 instructions.

I suppose what we really need is two distinct but related architectures; armv6-unknown-linux-gnueabihf and something armel related.

comment:5 Changed 3 years ago by erikd

@joeyhess, if you have access to an armel machine with Clang installed, get a simple C file (eg hello-world.c) and compile with clang capturing the LLVM IR output:

clang -S -emit-llvm foo.c

which will produce a foo.ll file containing the text LLVM IR code. If you could post the first 10 or so lines of that file (it should contain information about the target triple) that would be a good first step.

comment:6 Changed 3 years ago by joeyhess

The triple for armel is armv4t-unknown-linux-gnueabi

Note: See TracTickets for help on using tickets.