Segmentation fault when encountering a TemplateHaskell splice

[istathar]

We've had ghcide crashing, and the editor trying to reload it leads to a tight loop that the editor can't escape. Trying the ghcide binary from the command-line in test mode leads to a segfault:

Step 6/6: Type checking the files
Segmentation fault (core dumped)

This is triggered when using TemplateHaskell. We have a splice fromPackage :: Q Exp which returns some metadata from the project's .cabal file:

version :: Version
version = $(fromPackage)

removing this definition from the source file (in this case RenderMain.hs lines 13-14) allows the ghcide binary to complete its test run:

Step 6/6: Type checking the files

Completed (1 file worked, 0 files failed)

I had earlier speculated that QuasiQuotes were to blame, but the file checks ok with those [quote| ... |] blocks still in the file.

Other files in the project load and check fine, so long as you avoid having the problematic file open in an editor tab you can avoid the crash. Not ideal, but at least a workaround.

[ndmitchell]

Another workaround is to use #ifdef __GHCIDE__ around the problematic bit.

[istathar]

Fencing the splice with a preprocessor directive (and enabling CPP) indeed works to prevent ghcide from crashing.

version :: Version
#ifdef __GHCIDE__
version = "0"
#else
version = $(fromPackage)
#endif

Do you want a backtrace from when it segfaults? I've not had much success getting GDB to play nice with GHC but I'll give it a try if you want.

[ndmitchell]

If it's easy then sure, but I'm not sure if anyone is likely to look at it. TH related things aren't our strong spot.

[mpickering]

Is this reproducible @afcowie ?

[istathar]

@mpickering yes, very reproducible. I only have one Template Haskell splice in my collection of projects—only time I've ever written TH code—but I hazard a guess any Template Haskell splice would trigger this.

(this is to say I have three separate projects doing this in one file each and ghcide segfaults with all of them)

[mpickering]

Template Haskell does generally work so I think it is probably something specific to do with this splice.
What platform are you running on? What GHC version?

[mpickering]

fromPackage looks excessively dodgy. Perhaps the issue is that it is calling error which manifests as a segfault somehow. If you modify it to call fail does that improve the situation?

[istathar]

@mpickering I'm sorry you find our code excessively dodgy. We've avoided TemplateHaskell for years, seems to cause more problems that its worth but worked for us in this case. I'll try your suggestion.

[istathar]

@mpickering No, changing to fail doesn't change the outcome; still segfaults. I'll poke around in there to see if there's something else going on though.

[mpickering]

@afcowie Can you produce a standalone repo with a hie.yaml file which reproduces this and I will investigate.

[istathar]

@mpickering done. If you clone https://github.com/afcowie/hello/tree/ghcide-issue-444 you will get a essentially bare repository with a single program that demonstrates the problem. stack build should succeed; stack exec -- hello and/or stack run should result in "Hello World" on your console:

$ stack exec -- hello
Hello World
$

however

$ ghcide src/HelloMain.hs
Step 6/6: Type checking the files
Segmentation fault (core dumped)
$

I should note that this is with GHC 8.8.2 so you'll need the a version of ghcide built against that, as I understand it. The problem was exhibited with earlier versions of GHC. If you're using Stack but GHC 8.6.5, say, you can use:

resolver: lts-14.27

extra-deps:
  - core-text-0.2.3.3
  - core-data-0.2.1.5
  - core-program-0.2.4.2

and get the same demonstration.

[mpickering]

The segfault is coming from calling length in Data.Text.Short. Here is a more minimal example.

https://gist.github.com/d335ac940a97a574891c947578636fa1

[mpickering]

The ByteArray# and length look correct to me so something is going wrong with the call to c_text_short_length.

[mpickering]

To further deepen the mystery, if I add text-short as a local package, then it works, if it comes from the global cabal store then it doesn't. I'm going to stop investigating this bug now!