segmentation fault by compiling GHC

changed weight to 5

changed milestone to %8.2.1

The fact that this is DynFlags is suspicious. That module in particular takes quite a bit of memory to compile (especially at the moment, due to a known bug). Moreover, we have seen reports of segfaults on running out of memory. How much memory does your guest have available to it? Is this crash reproducible?

Reply to [[span(style=color: #FF0000, bgamari )]].\\

Is this crash reproducible?\\

Yes the crash is reproducible on my computer every time I run "make" or "make install"\\\\

How much memory does your guest have available to it?\\

my computer has 4 Go of RAM\\ Windows is 32 bit and use 3 Go of RAM. Linux is 64 bit on virtualBox as guest.\\ Linux use 1024 Mo of RAM.\\ in Linux, I looked at the task manager.\\ the memory in use does not exceed 83% when the compilation is active\\

vanto@debian:~/ghc$ make
===--- building phase 0
make --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for 'phase_0_builds'.
===--- building phase 1
make --no-print-directory -f ghc.mk phase=1 phase_1_builds
make[1]: Nothing to be done for 'phase_1_builds'.
===--- building final phase
make --no-print-directory -f ghc.mk phase=final all
"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Wall   -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header   -this-unit-id ghc-8.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2   -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.4.3.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.4.1 -package-id time-1.8.0.1 -package-id containers-0.5.10.2 -package-id array-0.5.1.2 -package-id filepath-1.4.1.1 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id hoopl-3.10.2.2 -package-id unix-2.7.2.1 -package-id terminfo-0.4.0.2 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O2  -no-user-package-db -rtsopts      -Wnoncanonical-monad-instances  -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build   -dynamic-too -c compiler/main/DynFlags.hs -o compiler/stage2/build/DynFlags.o -dyno compiler/stage2/build/DynFlags.dyn_o

When the DynFlags file is compiled I noticed this behavior (of memory) in the task manager of Linux:\\ throughout the process, which takes about 20 minutes, the memory that is used varies between 88% and 93% of the total memory.\\ suddenly the percentage of memory stops at 93% and does not vary thereafter for about 2 minutes.\\ then after this time elapsed the file stops to compile and an error appears.\\

compiler/ghc.mk:588: recipe for target 'compiler/stage2/build/DynFlags.o' failed
make[1]: *** [compiler/stage2/build/DynFlags.o] Erreur de segmentation
Makefile:122: recipe for target 'all' failed
make: *** [all] Error 2
vanto@debian:~/ghc$

the memory down to 7% after stopping compilation.\\ \\ In Windows, throughout the process in the guest I can read in the task manager that the memory in use is 2.08 GB of RAM all the time.

I just did another test.\\ I increased the memory of Linux in VirtualBox, 1514 Mo\\ during compilation the percentage of memory usage has reached 95%, and has never been beyond\\

I noticed a new fact.\\ compiling failed when the swap file has reached 100% with the same error message.\\ \\ Hope this help

Remember Linux, depending on its VM settings often overcommits itself. Suggest you allow the virtual machine far more memory than currently.

More generally having a 64-bit (virtual or otherwise) machine and not giving it a few gigabytes at least (costing less then the time you're waiting for it) is silly.

changed milestone to %8.4.1

Given that 8.2.1-rc1 is imminent, I'm bumping these off to the 8.4

changed milestone to %8.6.1

This ticket won't be resolved in 8.4; remilestoning for 8.6. Do holler if you are affected by this or would otherwise like to work on it.

closed

It seems pretty clear that the original problem here was the user was running out of memory. I believe I have fixed the segmentation fault on out-of-memory condition, so we should fail more gracefully now.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

The new Hadrian build system has been merged. Relabeling the tickets concerning the legacy make build system to prevent confusion.

Trac metadata

Trac field	Value
Component	Build System → Build System (make)

added ghc build failure label

added Pnormal label

Hi, I just ran into this issue while building 8.8.4. I could fix it by reducing the number of jobs allowed for make. Over 2.8 GB of memory were used during the compilation of DynFlags.

Trac field	Value
Version	8.0.2
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Build System
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

segmentation fault by compiling GHC

Child items ...

Activity