#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