mkTopLevEnv: not interpreted main:Main

[Chris Smith]

So I'm trying to fix a bug in a web application that's using the GHC API
with GHC 7.2.  If it helps, the application is gloss-web, source code at
https://github.com/cdsmith/gloss-web and the relevant module is
src/Source.hs.

The error I'm getting is

    <no location info>: mkTopLevEnv: not interpreted main:MyModule

I get this occasionally when two pieces of source code happen to get
compiled at approximately the same time, but most of the time everything
works fine.  The module name there is whichever one I've defined in the
source code I'm compiling.  It's correct that the module is not
interpreted; I'm specifying options

    hscTarget = HscAsm
    ghcLink = LinkInMemory

But it's unclear to me why GHC occasionally decides to require that it
be interpreted and complain, when compiling the code works fine in any
other circumstance.  Anyone else seen anything like this, or know what
the cause is?

A few notes:

1. It doesn't appear to be a straight-forward reentrancy issue, as
wrapping uses of the GHC API with an MVar lock doesn't affect it at all.
However, it definitely *is* correlated with multiple compiles at
approximately the same time.  Very odd there.

2. On a whim, I tried adding a performGC before and after each use of
the compiler to try to isolate the uses of the GHC API more completely.
Oddly enough, a performGC before the compile makes the problem much
WORSE.  I found that interesting; maybe it's a hint.

3. If you want to build my code and reproduce it, the easiest way is to
comment out line 110 (keepAlive cmap digest 30) of src/Source.hs.  Doing
so will break the bit that caches recently compiled source code, making
it much easier to actually call the GHC API several times in rapid
succession just by rapidly clicking the Run button in the web app.

If there's anything I can do to get more information, I'm happy to do so
as well.  I'm not terribly familiar with the flags or options for GHC,
as I've never done this before.

-- 
Chris Smith