GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits

Windows shows a window that says "GHC has stopped working" when compiling a simple hello world.

Steps to reproduce

1. Download GHC 7.8 RC2 (http://www.haskell.org/ghc/dist/7.8.1-rc2/ghc-7.8.0.20140228-i386-unknown-mingw32.tar.bz2)
2. Extract the contents of the tar to folder
   $GHC$
3. Add
   $GHC$
   \bin and
   $GHC$
   \mingw\bin folder to the PATH, add env var "LANG=C".
4. Create file test.hs with contents:

main = putStrLn "Hello, World!"

5. run "ghc test.hs".

Interestingly, the error is not deterministic, ie, after running the command several times the program gets compiled. When that happens, and ff the file test.o is not deleted, further attempts to compile run succesfully.

GHCi appears to work normally (when doing simple tests).

More details: http://stackoverflow.com/questions/22291739/cant-install-packages-with-cabal-using-ghc-7-8rc2-and-windows-7

Trac metadata

Trac field	Value
Version	7.8.1-rc2
Type	Bug
TypeOfFailure	OtherFailure
Priority	highest
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

mentioned in issue #8707 (closed)

mentioned in issue #8834 (closed)

changed weight to 10

added Tbug Trac import labels

I can reproduce this, and it actually always fails for me.

This looks serious, as in a release blocker. And it looks like it's the same as the problem I've been encountering when building on Window: http://www.haskell.org/pipermail/ghc-devs/2014-March/004189.html. Notice the crash happens for me after a couple of CPSZ messages have come out, same as reported above on !StackOverflow.

But hello-world failing is much easier to track down than GHC itself failing.

Could anyone git-bisect their way to the commit that did this?

Simon

changed milestone to %7.8.1

Austin says: if ghc-stage2 is seg-faulting, try re-linking it with the debug runtime system, thus

cd ./ghc
make re2 GhcDebugged=YES

and now try the seg-faulting ghc-stage2 again.

Also https://ghc.haskell.org/trac/ghc/wiki/Debugging/CompiledCode

When i run ghc from within gdb I consistently get it to successfully compile and link the program.

edit: ignore the above, it now also starts failing again under gdb

See also #8834 (closed)

mentioned in issue #8890 (closed)

See also #8890 (closed)

changed milestone to %7.8.2

changed weight to 7

After testing and investigation, we believe this is related to #8834 (closed) - but also, we can't easily reproduce this. So I'm lowering the priority and marking this to 7.8.2. I will thoroughly test with the Windows distribution (coming soon).

BTW: what version of Windows are you using?

Trac metadata

Trac field	Value
Priority	highest → high

I'm using Windows 7 32 bits; I don't have the time/experience to build ghc with patches, but can test binary distributions to see if the problem disappeared.

Note the discussion continuing on from #8834 (closed)##8870 (closed)

changed milestone to %7.8.1

@Simon, I've tried sprinkling some NOINLINE to see if it has any effect on pressure the codegen might be under - indeed, if I sprinkle a few NOINLINE here and there like on genCCall (a massive piece of code in its own right), then System.Time does compile, but DPH fails to compile later on:

libraries/dph/dph-lifted-vseg/ghc.mk:5: recipe for target 'libraries/dph/dph-lifted-vseg/dist-install/build/Data/Array/Parallel/PArray/PData/Base.p_o' failed
make[1]: *** [libraries/dph/dph-lifted-vseg/dist-install/build/Data/Array/Parallel/PArray/PData/Base.p_o] Segmentation fault

I'm checking if this is the same thing as before right now.

I will note that in the example I posted in the other comment, a292_rFAj at the STG level - which roughly corresponds to stmtToInstrs - is absolutely massive - by itself, it's on the order of 24,000 lines of intermediate code long. X86.CodeGen really only exports cmmTopCodeGen, so it probably goes to town on the module, inlining like crazy, since stmtToInstrs is at the heart of it.

I don't quite understand how could I reproduce it. Even running GHC under MSYS2 I can't get it segfaulting. If sitting on 64-bit windows shall I use 32-bit MSYS2 to reproduce it?

Also growing stack by more than 1 page is a *definite* bug in Windows. And there are many discussions on this here and there.

As a temporary workaround could we simply increase reserved *and* committed stack size in an executable's header making GHC invoke linker with right options when producing executables - something like -optl-Xlinker -optl--stack=0x800000,0x800000? This would make things more or less like they are under Linux/OSX. Or we need to access intermediate addresses anyway? If so, to speed things up we could use already existent __chkstk function.

Does committing more stack space have any adverse effects? Startup time and/or making our processes unnecessarily large?

Replying to [ticket:8870#comment:81032 simonmar]:

Does committing more stack space have any adverse effects? Startup time and/or making our processes unnecessarily large?

These effects look absolutely negligible to me.

OTOH, it improves performance if we ever want more than 1 page of stack in one shot.

mentioned in commit f0af58df

closed

This should now be fixed. GHC passes -Xlinker --stack=0x800000,0x800000 to gcc now, which reserves and commits 8MB up front (2mb is enough to fix this, but 8 is quite generous).

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

reopened

added 1 deleted label

closed

Merged.

removed 1 deleted label

mentioned in issue #12186 (closed)

Trac metadata

Trac field	Value
Related	- → #12186 (closed)
CC	simonmar → simonmar, tim-m89

mentioned in commit 1e795a00

mentioned in issue #13100 (closed)

added compiler crash label

added Phigh label