Stack: GHC access violation on official Windows 10 VM

Created on 21 Jul 2020  ·  5Comments  ·  Source: commercialhaskell/stack

I recently wanted to start compiling one of my projects on Windows as well as on Linux. I downloaded the official Windows 10 VM for Virtualbox from developer.microsoft.com and installed Stack there. Unfortunately, any project I tried to compile there fails with an Acces violation error.

Steps to reproduce

1, Download official Windows 10 VM image (tested with Virtualbox image).

  1. Launch it and install Stack.
  2. Create a new Stack project and build it.

Expected

The new project should compile successfully.

Actual

Compilation fails.

C:\Users\User\test>stack build
Building all executables for `test' once. After a successful build of all of them, only specified executables will be rebuilt.
test> configure (lib + exe)
Configuring test-0.1.0.0...

Access violation in generated code when writing 0x0

 Attempting to reconstruct a stack trace...

   Frame        Code address
 * 0x461da80    0x37f7b66 C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\ghc-8.8.3\bin\ghc.exe+0x33f7b66
 * 0x461da88    0x3277bb9 C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\ghc-8.8.3\bin\ghc.exe+0x2e77bb9
 * 0x461da90    0x5
 * 0x461da98    0x5
 * 0x461daa0    0x3d7dc22 C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\ghc-8.8.3\bin\ghc.exe+0x397dc22
 * 0x461daa8    0x62c3db0


--  While building package test-0.1.0.0 using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_3.0.1.0_ghc-8.8.3.exe --builddir=.stack-work\dist\29cc6475 configure --user --package-db=clear --package-db=global --package-db=C:\sr\snapshots\b2bcbb23\pkgdb --package-db=C:\Users\User\test\.stack-work\install\618fdf1f\pkgdb --libdir=C:\Users\User\test\.stack-work\install\618fdf1f\lib --bindir=C:\Users\User\test\.stack-work\install\618fdf1f\bin --datadir=C:\Users\User\test\.stack-work\install\618fdf1f\share --libexecdir=C:\Users\User\test\.stack-work\install\618fdf1f\libexec --sysconfdir=C:\Users\User\test\.stack-work\install\618fdf1f\etc --docdir=C:\Users\User\test\.stack-work\install\618fdf1f\doc\test-0.1.0.0 --htmldir=C:\Users\User\test\.stack-work\install\618fdf1f\doc\test-0.1.0.0 --haddockdir=C:\Users\User\test\.stack-work\install\618fdf1f\doc\test-0.1.0.0 --dependency=base=base-4.13.0.0 --extra-include-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20180531\mingw64\include --extra-lib-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20180531\mingw64\lib --extra-lib-dirs=C:\Users\User\AppData\Local\Programs\stack\x86_64-windows\msys2-20180531\mingw64\bin --exact-configuration --ghc-option=-fhide-source-paths
    Process exited with code: ExitFailure 11

Stack version

$ stack --version
Version 2.3.1, Git revision de2a7b694f07de7e6cf17f8c92338c16286b2878 (8103 commits) x86_64 hpack-0.33.0

Method of installation

Installer downloaded from: haskellstack.org.

windows upstream issue

Most helpful comment

Stackage now has resolvers for GHC 8.8.4, most recently lts-16.15.

All 5 comments

I am having similar issues when running 'stack install' on any packages it seems. I also have the problem when running 'stack setup --resolver lts-16.7'. In my case the issues seem to be connected to the fact that i had a previous installation of haskell platform which has since been deleted. I say this because these problem do not occur on my other windows machine with no installations of anything related to haskell.

This is similar to what I've been facing while trying to run stack setup, see #5313 . It seems to affect any LTS with GHC 8.8.3.

For anyone else having this issue on Windows 10 while the current Stackage LTS resolver is still using GHC 8.8.3, try either of the following:

  • Run your stack commands with the ghc-8.8.4 compiler flag. e.g. stack build --compiler=ghc-8.8.4 --resolver=lts-16.8, or
  • Edit your project's stack.yaml file to include the line compiler: ghc-8.8.4. I put mine right below the resolver line :)

GHC 8.8.4 has been released with some backported fixes that should cover this issue. I'm unsure what Stackage's timeline is re: bumping the current LTS 16.x generation to use GHC 8.8.4, but the above suggestions should cover you in the interim. Hopefully soon.

@and-pete Indeed, it works.

Stackage now has resolvers for GHC 8.8.4, most recently lts-16.15.

Was this page helpful?
0 / 5 - 0 ratings