TH with -split-sections fails to compile on Windows with GHC 9.4.7/9.6.2
Summary
When I try to compile the minimal reproduction I provide below with -split-sections
I get the following error:
C:\Users\csasarak>ghc -split-sections TH.hs THUsage.hs
[1 of 2] Compiling TH ( TH.hs, TH.o )
[2 of 2] Compiling THUsage ( THUsage.hs, THUsage.o )
Access violation in generated code when executing data at 0x7ff7766564e0
Attempting to reconstruct a stack trace...
Frame Code address
* 0xdcc70fdb40 0x7ff7766564e0 C:\Users\csasarak\TH.o+0x18
(TH_makeDecl_info+0x0)
I executed this on a Windows 11 Home system running on my Mac using Parallels.
The real world case I first saw this in was during a build for my company on Github's Windows Server 10 runner. The TH definition and the call that triggers that error are publicly viewable.
Steps to reproduce
With GHC 9.4.7 on Windows 10 or 11 do the following:
- Create a file called
TH.hs
with the following contents:
{-# LANGUAGE TemplateHaskell #-}
module TH (
makeDecl
) where
import Language.Haskell.TH
makeDecl :: Name -> Q [Dec]
makeDecl declName = pure <$> valD (varP declName) (normalB . litE . stringL $ "bar") []
- In the same directory as (1), create a file called
THUsage.hs
with the following contents:
{-# LANGUAGE TemplateHaskell #-}
module THUsage where
import TH
import Language.Haskell.TH
$(makeDecl (mkName "foo"))
- Compile both files with
ghc -split-sections TH.hs THUsage.hs
.
I have tested this with GHC 9.2.8 and it doesn't appear to exhibit the bug with this reproducer on Windows 11.
In my testing I tried a few different options to see what triggered the error and what didn't.
The results seemed a bit sensitive to the *.o
and *.hi
files left-over from previous tries, so if you try changing options I'd recommend deleting those intermediate files between runs of ghc.
Expected behavior
I expect compilation to finish successfully and be left with two *.o
files in the current working directory.
Environment
- GHC version used: 9.4.7 and 9.6.2
Optional:
- Operating System: Windows 10/11 (I have not tested 9.2 or 9.6 with Windows 10)
- System Architecture: Amd64
Workaround
Not compiling with -split-sections
seems to makes this go away.
The last version of GHC we used in our CI with working -split-sections
was 9.0
(we're upgrading from 9.0
->9.4
). Comparing a 9.4 without -split-sections
and 9.0
with it, the difference doesn't seem substantial. The increase was from about 122 MB to 128 MB.
My understanding is that the default does not enable -split-sections
on Windows, so it may be unlikely for folks encounter this.