[GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff.
GHC
ghc-devs at haskell.org
Fri Sep 7 13:44:07 UTC 2018
#13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff.
---------------------------------+--------------------------------------
Reporter: awson | Owner: (none)
Type: bug | Status: infoneeded
Priority: normal | Milestone:
Component: Compiler | Version: 8.1
Resolution: | Keywords:
Operating System: Windows | Architecture: x86_64 (amd64)
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
---------------------------------+--------------------------------------
Comment (by jbransen):
With GHC 8.4.3 I am also experiencing segfaults on my 64-bit Windows 10
machine, and I'd like to add some observations that can hopefully help
pinpoint the exact problem:
- I am working on a relatively big package with many dependencies, amongst
which is `persistent`, and the segfault happens when compiling the first
module containing TH code calling persistent generation.
- With GHC 8.2 on the same codebase, the segfaults seemed to appear only
when compiling a module with TH for the first time. Building again then
worked. With GHC 8.4 the segfault is consistent.
- Using `-fexternal-interpreter` solves the problem, but since that is not
compatible with intero, it breaks my editor integration and does not help
me so much. I've also tried haskell-ide-backend which segfaults in the
same way...
- I am using Stack, and `stack build` fails with a segfault, but `stack
repl` (so using ghci) does work!
- I tried to create a minimal example, but I can't. I started to strip
down as much as possible, and I now have a strange project which does
consistently generate a segfault. However, when I remove some unused (!)
import, or some unused (!) dependency from the .cabal file, it does
compile. It does not seem to matter so much what I remove, so it really
seems like it is related to the amount of dependencies that are in scope.
My guess is that somehow it is related to how much is loaded into memory,
and that after some threshold we end up in large address space. Hence, I
have the feeling there is no "minimal example" triggering this bug...
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13112#comment:30>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list