Segfault in a CoreLinted program (and a GHC-generated Core question)

Ömer Sinan Ağacan omeragacan at
Mon Oct 26 16:32:27 UTC 2015

I have a very simple Core plugin that generates some functions. After my
Core-to-Core pass is done, I'm running the linter to make sure the Core
generated by my plugin is well-formed and well-typed. However, even though lint
checker passes, the code generated by my plugin is failing with a segfault.

I created a git repo for demonstration:

This is where the CoreLint is happening:

I'm using GHC HEAD(it doesn't build with 7.10). Here's how to run:

Make sure GHC HEAD is in the $PATH, then

    $ cabal install --with-ghc=ghc-stage2
    $ cd test

Adding bunch of -ddump parameters here for debugging purposes:

    $ ghc-stage2 -fplugin=Plugins --make Main.hs -fforce-recomp
-ddump-simpl -ddump-ds -ddump-to-file -ddump-stg

Now if you run the generated program, it should first print some numbers and
then segfault.


I heard from Simon in various talks(e.g. Haskell exchange 2015) that if lint
passes, then there should be no segfaults, so I thought this should be a bug.
I'm actually having some other problems with CoreLint too, for example, even
though Core lint passes, if I run Core simplifier pass after my plugin runs,
GHC is failing with various different panics. Some of those panics are
happening inside STG generation, not in simplifier(but it works fine if I
disable the simplifier!) It seems like CoreLint is not strict enough, it's not
checking some invariants that GHC simplifier and STG code generator are

So my questions are: Am I right in assuming that CoreLint accepted programs
should not segfault? What about internal invariants? Should CoreLint check for
those? Is there any pass that checks for invariants and prints helpful messages
in case of a invariant invalidation?

As an attempt at debugging the code generated by my plugin, I wrote the
function that is supposed to be generated by my Core pass in Haskell and
compiled with GHC. Generated Core is mostly the same, except at one point it
has an extra lambda directly applied to a void#, something like ((\_ -> ...)
void#). Where can I learn more about why GHC is doing that?


More information about the ghc-devs mailing list