Opened 4 years ago

Closed 3 years ago

#9268 closed bug (fixed)

internal error: evacuate(static): strange closure type -385875968

Reported by: brbr Owned by:
Priority: high Milestone: 7.10.1
Component: Compiler Version: 7.8.2
Keywords: Cc:
Operating System: Linux Architecture: Unknown/Multiple
Type of failure: Building GHC failed Test Case:
Blocked By: #9439 Blocking:
Related Tickets: #8976 Differential Rev(s):
Wiki Page:

Description (last modified by brbr)

From a fresh checkout

$ git describe 

and "make -j3" of the "quick-llvm" profile:

inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet"
dll-split: internal error: evacuate(static): strange closure type -385875968
    (GHC version 7.9.20140704 for x86_64_unknown_linux)
    Please report this as a GHC bug:
make[1]: *** [compiler/stage2/dll-split.stamp] Aborted (core dumped)
make[1]: *** Waiting for unfinished jobs....
<<ghc: 1842198088 bytes, 249 GCs, 9848554/24268488 avg/max bytes residency (7 samples), 62M in use, 0.00 INIT (0.00 elapsed), 1.54 MUT (3.48 elapsed), 0.35 GC (0.37 elapsed) :ghc>>
make: *** [all] Error 2

Host GHC:

$ ghc --info
 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts"," -fwrapv")
 ,("C compiler command","/usr/bin/gcc")
 ,("C compiler flags"," -fno-stack-protector")
 ,("C compiler link flags","")
 ,("ld command","/usr/bin/ld")
 ,("ld flags","")
 ,("ld supports compact unwind","YES")
 ,("ld supports build-id","YES")
 ,("ld supports filelist","NO")
 ,("ld is GNU ld","YES")
 ,("ar command","/usr/bin/ar")
 ,("ar flags","q")
 ,("ar supports at file","YES")
 ,("touch command","touch")
 ,("dllwrap command","/bin/false")
 ,("windres command","/bin/false")
 ,("libtool command","libtool")
 ,("perl command","/usr/bin/perl")
 ,("target os","OSLinux")
 ,("target arch","ArchX86_64")
 ,("target word size","8")
 ,("target has GNU nonexec stack","True")
 ,("target has .ident directive","True")
 ,("target has subsections via symbols","False")
 ,("LLVM llc command","llc")
 ,("LLVM opt command","opt")
 ,("Project version","7.8.2")
 ,("Booter version","7.4.1")
 ,("Build platform","x86_64-unknown-linux")
 ,("Host platform","x86_64-unknown-linux")
 ,("Target platform","x86_64-unknown-linux")
 ,("Have interpreter","YES")
 ,("Object splitting supported","YES")
 ,("Have native code generator","YES")
 ,("Support SMP","YES")
 ,("Tables next to code","YES")
 ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn")
 ,("Support dynamic-too","YES")
 ,("Support parallel --make","YES")
 ,("Dynamic by default","NO")
 ,("GHC Dynamic","YES")
 ,("Leading underscore","NO")
 ,("Debug on","False")
 ,("Global Package DB","/home/brian/stage/ghc-7.8.2-install/lib/ghc-7.8.2/package.conf.d")

Change History (11)

comment:1 Changed 4 years ago by brbr

Description: modified (diff)

comment:2 Changed 4 years ago by brbr

Issue not seen with "quick" profile.

comment:3 Changed 4 years ago by thoughtpolice

Milestone: 7.10.1

Moving to 7.10.1.

comment:4 Changed 3 years ago by rwbarton

This happened to me too trying to build the ghc-7.8 branch with "perf-llvm". Same closure type number, even.

comment:5 Changed 3 years ago by rwbarton

I'm having a strong sense of deja vu here.

(gdb) print p->payload[0]
$19 = (struct StgClosure_ *) 0x7fc6475e2861 <stg_CHARLIKE_closure+1825>
(gdb) print *((struct StgClosure_ *)0x7fc6475e2860)
$20 = {header = {info = 0x403310 <ghczmprim_GHCziTypes_Czh_static_info@plt>}, payload = 0x7fc6475e2868 <stg_CHARLIKE_closure+1832>}

Note the info pointer pointing into the PLT. That's not good, there is no info table before the PLT entry!

I seem to recall debugging the same issue and the problem being that LLVM was emitting @functions instead of @objects. Somehow the LLVM mangler isn't doing its job. But I don't understand why not. It seems to operate properly when I run it manually.

Perhaps I should try building the stage1 compiler with the NCG and then the RTS and libraries with -fllvm, in case there is some pernicious bug in the LLVM backend affecting the LLVM mangler...

comment:6 Changed 3 years ago by rwbarton

Building stage1 with the NCG made no difference, which is good, I guess.

comment:7 Changed 3 years ago by rwbarton


So whatever changes I made to mk/ didn't have the expected effect, for some reason, and the stage1 compiler was still being built with -fllvm.

And of course the bootstrapping compiler has an LLVM mangler too, which goes about replacing @function with @object in the assembly output from LLVM.

But I was building the mangler for the stage1 compiler with -fllvm, and of course it contains the string constant @function so that it knows what to replace with @object. So when the bootstrapping mangler mangled the stage1 mangler it also replaced that string constant @function by @object meaning the stage1 mangler was actually replacing @object with @object!

So various things such as ghczmprim_GHCziTypes_Czh_static_info still had type @function after being mangled by the stage1 compiler, which led to this crash.

Maybe we can tell LLVM to output @objects in the first place somehow? Or be more selective about our mangling...

comment:8 Changed 3 years ago by rwbarton

comment:9 Changed 3 years ago by rwbarton

Blocked By: 9439 added

This should be fixed when #9439 is.

comment:10 Changed 3 years ago by rwbarton

This is now fixed in HEAD. Note that you probably need to use a bootstrapping compiler that is not affected by this bug, currently meaning 7.6.3 or earlier.

trac doesn't want to let me close the ticket because it's blocked by #9439 which is in 'merge' status.

comment:11 Changed 3 years ago by thomie

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.