Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows 10: can't build 0.4.0.1 using GHC 8.6.3 (stack, lts-13.0) #93

Closed
mpilgrem opened this Issue Dec 29, 2018 · 9 comments

Comments

Projects
None yet
3 participants
@mpilgrem
Copy link

mpilgrem commented Dec 29, 2018

I do not know where the problem lies, but I am unable to build generics-sop-0.4.0.1 using stack with resolver lts-13.0 (GHC 8.6.3) on Windows 10 64-bit. After the configure and build steps are reported by stack, there is no further progress (even though ghc.exe continues to use most of the CPU for long periods of time - on a laptop with an Intel Core i7-8550U CPU).

(GHC 8.6.3 seems to be part of the problem: changing the resolver to lts-12.25 - GHC 8.4.4 - sees generics-sop-0.3.2.0 build fine and quite quickly. Adding extra-deps generics-sop-0.4.0.1 and sop-core-0.4.0.0 also sees a quick successful build with GHC 8.4.4.)

For example, the following sequence of activities results in no progress beyond Progress 0\2, even if I wait a long time:

>stack new sopTest
>cd sopTest
[Edit `package.yaml` to add `- generics-sop` as a dependency]
>stack build
generics-sop-0.4.0.1: configure
generics-sop-0.4.0.1: build
Progress 0/2

stack build --dry-run yields:

No packages would be unregistered.

Would build:
generics-sop-0.4.0.1: database=snapshot, source=generics-sop-0.4.0.1@sha256:6474ad47a9dbcedc3c721b8d582d00ea52ec9fe6c5327562d0aeaa6f878ace91,5529 (from Hackage)
sopTest-0.1.0.0: database=local, source=C:\Users\mikep\Documents\Code\Haskell\sopTest\, after: generics-sop-0.4.0.1

No executables to be installed.

stack --verbose build yields for the last three lines of logging (before no further progress is made):

[debug] Finished writing C:\Users\mikep\AppData\Local\Temp\stack25088\generics-sop-0.4.0.1\.stack-work\dist\e626a42b\stack-config-cache
2018-12-29 16:53:34.344575: [info] generics-sop-0.4.0.1: build
2018-12-29 16:53:34.344575: [debug] Run process within C:\Users\mikep\AppData\Local\Temp\stack25088\generics-sop-0.4.0.1\: C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.4.0.1_ghc-8.6.3.exe --builddir=.stack-work\dist\e626a42b build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
Progress 0/2

For completeness, stack --version is Version 1.10.0, Git revision 8e3490566b8e2846d99219156bee47047bd44564 (6723 commits) x86_64 hpack-0.31.1.

@kosmikus

This comment has been minimized.

Copy link
Member

kosmikus commented Dec 29, 2018

How much RAM does the machine have? My only theory at this point is that it is a compiler performance problem. Could you try calling stack build --interleaved-output and see where exactly it hangs? The most memory-hungry module by far is Generics.SOP.Instances. It's possible that it's somehow even worse with 8.6.3 than 8.4.4, and it's also possible that it's worse on Windows for some reason.

If that's it, it might be possible to split the module into several smaller ones.

If not, we'll have to look further.

@kosmikus kosmikus self-assigned this Dec 29, 2018

@mpilgrem

This comment has been minimized.

Copy link
Author

mpilgrem commented Dec 29, 2018

The machine has 8 GB installed RAM (7.73 GB usable). The output from stack build --interleaved-output is below - it looks like Generics.SOP.Instances is the problem:

generics-sop-0.4.0.1: configure
generics-sop> Configuring generics-sop-0.4.0.1...
generics-sop-0.4.0.1: build
generics-sop> Preprocessing library for generics-sop-0.4.0.1..
generics-sop> Building library for generics-sop-0.4.0.1..
generics-sop> [ 1 of 14] Compiling Generics.SOP.BasicFunctors ( src\Generics\SOP\BasicFunctors.hs, .stack-work\dist\e626a42b\build\Generics\SOP\BasicFunctors.o )
generics-sop> [ 2 of 14] Compiling Generics.SOP.Classes ( src\Generics\SOP\Classes.hs, .stack-work\dist\e626a42b\build\Generics\SOP\Classes.o )
generics-sop> [ 3 of 14] Compiling Generics.SOP.Constraint ( src\Generics\SOP\Constraint.hs, .stack-work\dist\e626a42b\build\Generics\SOP\Constraint.o )
generics-sop> [ 4 of 14] Compiling Generics.SOP.Dict ( src\Generics\SOP\Dict.hs, .stack-work\dist\e626a42b\build\Generics\SOP\Dict.o )
generics-sop> [ 5 of 14] Compiling Generics.SOP.NP  ( src\Generics\SOP\NP.hs, .stack-work\dist\e626a42b\build\Generics\SOP\NP.o )
generics-sop> [ 6 of 14] Compiling Generics.SOP.Metadata ( src\Generics\SOP\Metadata.hs, .stack-work\dist\e626a42b\build\Generics\SOP\Metadata.o )
generics-sop> [ 7 of 14] Compiling Generics.SOP.NS  ( src\Generics\SOP\NS.hs, .stack-work\dist\e626a42b\build\Generics\SOP\NS.o )
generics-sop> [ 8 of 14] Compiling Generics.SOP.Sing ( src\Generics\SOP\Sing.hs, .stack-work\dist\e626a42b\build\Generics\SOP\Sing.o )
generics-sop> [ 9 of 14] Compiling Generics.SOP.Type.Metadata ( src\Generics\SOP\Type\Metadata.hs, .stack-work\dist\e626a42b\build\Generics\SOP\Type\Metadata.o )
generics-sop> [10 of 14] Compiling Generics.SOP.GGP ( src\Generics\SOP\GGP.hs, .stack-work\dist\e626a42b\build\Generics\SOP\GGP.o )
generics-sop> [11 of 14] Compiling Generics.SOP.Universe ( src\Generics\SOP\Universe.hs, .stack-work\dist\e626a42b\build\Generics\SOP\Universe.o )
generics-sop> [12 of 14] Compiling Generics.SOP.TH  ( src\Generics\SOP\TH.hs, .stack-work\dist\e626a42b\build\Generics\SOP\TH.o )
generics-sop> [13 of 14] Compiling Generics.SOP.Instances ( src\Generics\SOP\Instances.hs, .stack-work\dist\e626a42b\build\Generics\SOP\Instances.o )
Progress 0/2
@mpilgrem

This comment has been minimized.

Copy link
Author

mpilgrem commented Dec 29, 2018

The problem seems to be specific to GHC 8.6.3. If I switch to resolver nightly-2018-12-17 and GHC 8.6.2, it quickly builds generics-sop-0.4.0.1.

@mpilgrem

This comment has been minimized.

Copy link
Author

mpilgrem commented Dec 30, 2018

I am wondering if this could be a manifestation of GHC bug #16057. That talks about GHC 8.6.3 hanging on Windows.

@kosmikus

This comment has been minimized.

Copy link
Member

kosmikus commented Dec 30, 2018

I guess it's possible that it's this particular GHC bug. The Instances module is not just the most memory-hungry, but also the only one that makes use of TH.

Unfortunately, I cannot test on Windows myself. Can you observe memory and CPU consumption at the point in time when GHC seems to hang?

I could try to split the instances module into smaller submodules and we could see if it makes a difference. I have been considering this a number of times already. However, if an actual GHC bug is responsible, I'm not sure if this would help here.

@mpilgrem

This comment has been minimized.

Copy link
Author

mpilgrem commented Dec 30, 2018

It seems to me sensible to wait for GHC 8.6.4 and then see. Memory consumption while GHC is hanging does not seem to be excessive (55% used):

image

and the same is true of CPU consumption (26% used):

image

@RyanGlScott

This comment has been minimized.

Copy link
Contributor

RyanGlScott commented Jan 25, 2019

This is absolutely due to Trac #16057, as literally any use of Template Haskell splices with GHC 8.6.3 on Windows will cause it to hang forever. This should be addressed in an upcoming minor release of GHC 8.6, but until then, there's not much one can really do about this except downgrade to 8.6.2.

@RyanGlScott

This comment has been minimized.

Copy link
Contributor

RyanGlScott commented Mar 6, 2019

Trac #16057 has been fixed in GHC 8.6.4. @mpilgrem, do you still experience this issue when building with 8.6.4?

@mpilgrem

This comment has been minimized.

Copy link
Author

mpilgrem commented Mar 7, 2019

I can confirm this problem does not occur with GHC 8.6.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.