#8870 closed bug (fixed)

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

Reported by: facundoq Owned by:
Priority: high Milestone: 7.8.1
Component: Compiler Version: 7.8.1-rc2
Keywords: Cc: simonmar
Operating System: Windows Architecture: x86
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

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

Change History (20)

comment:1 Changed 15 months ago by dreixel

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

comment:2 Changed 15 months ago by simonpj

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

Last edited 15 months ago by simonpj (previous) (diff)

comment:3 Changed 15 months ago by thoughtpolice

  • Milestone set to 7.8.1

comment:4 Changed 15 months ago by simonpj

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

comment:5 Changed 15 months ago by darchon

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

Version 0, edited 15 months ago by darchon (next)

comment:6 Changed 15 months ago by simonpj

See also #8834

comment:7 Changed 15 months ago by simonpj

See also #8890

comment:8 Changed 14 months ago by thoughtpolice

  • Milestone changed from 7.8.1 to 7.8.2
  • Priority changed from highest to high
  • Status changed from new to infoneeded

After testing and investigation, we believe this is related to #8834 - 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?

comment:9 Changed 14 months ago by facundoq

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.

comment:10 Changed 14 months ago by thoughtpolice

Note the discussion continuing on from https://ghc.haskell.org/trac/ghc/ticket/8834#comment:79

comment:11 Changed 14 months ago by thoughtpolice

  • Milestone changed from 7.8.2 to 7.8.1

comment:12 Changed 14 months ago by simonmar

  • Cc simonmar added

comment:13 Changed 14 months ago by thoughtpolice

@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.

comment:14 Changed 14 months ago by awson

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.

Last edited 14 months ago by awson (previous) (diff)

comment:15 follow-up: Changed 14 months ago by simonmar

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

comment:16 in reply to: ↑ 15 Changed 14 months ago by awson

Replying to 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.

Last edited 14 months ago by awson (previous) (diff)

comment:17 Changed 14 months ago by Austin Seipp <austin@…>

In f0af58df4b5d5ace750e7d7a91ad471284c1b429/ghc:

windows: Fix #8870

This bumps the amount of default reserved and committed stack for GHC
executables to 8mb, to work around #8870. A proper fix should happen in
7.8.2

See note [Windows stack usage] in SysTools for the details.

Signed-off-by: Austin Seipp <[email protected]>

comment:18 Changed 14 months ago by thoughtpolice

  • Resolution set to fixed
  • Status changed from infoneeded to 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).

comment:19 Changed 14 months ago by thoughtpolice

  • Status changed from closed to merge

comment:20 Changed 14 months ago by thoughtpolice

  • Status changed from merge to closed

Merged.

Note: See TracTickets for help on using tickets.