[GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff.

[GHC]

#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