Opened 7 years ago

Closed 6 years ago

#5527 closed bug (fixed)

mkTopLevEnv: not interpreted

Reported by: cdsmith Owned by: pcapriotti
Priority: normal Milestone: 7.6.1
Component: GHC API Version: 7.3
Keywords: Cc:
Operating System: Linux Architecture: x86
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


When attempting to compile, load, and use a module several times per second with the GHC API, the compiler sometimes reports an error "mkTopLevEnv: not interpreted" for the module being loaded, even when that module isn't supposed to be interpreted.

The attached file exhibits the bug when runs multiple times in quick succession (less than a second apart). The important ingredients are:

  1. The same file is being compiled each time.
  2. The .hi and .o files still exist from the previous compile.
  3. The compiles are happening less than a second apart.

There's some suspicion that this is a problem with timestamp resolution.

This happens at least as far back as 7.1, and has been confirmed in the latest i386-linux development snapshot (7.3, from Sep 6, 2011). The attached code is for 7.3, but analogous code for older versions shows the same bug.

Attachments (2)

Test.hs (881 bytes) - added by cdsmith 7 years ago.
Test case
5527.patch (4.0 KB) - added by pcapriotti 6 years ago.

Download all attachments as: .zip

Change History (12)

Changed 7 years ago by cdsmith

Attachment: Test.hs added

Test case

comment:1 Changed 7 years ago by cdsmith

Architecture: Unknown/Multiplex86
Operating System: Unknown/MultipleLinux

comment:2 Changed 7 years ago by simonpj

See this thread for more details:, including various situations in which the bug does or does not manifest itself.

comment:3 Changed 7 years ago by simonmar


  • In this particular use case, it is better use use "*A.hs" instead of "A.hs" for the target, as this tells GHC that you want the module to be interpreted so that you can have its entire top-level scope available for interactive evaluation.
  • We should make GHC.setContext emit a proper exception in this case, instead of the cryptic mkTopLevEnv error.
  • There are strange things afoot with -fobject-code too: #5534

comment:4 Changed 7 years ago by simonmar

One more thing: there's a comment about the behaviour when the timestamps of the .o and .hs file match, in compiler/main/GhcMake.hs in the function checkStability. I'll add a pointer to this ticket from the comment.

comment:5 Changed 7 years ago by igloo

Milestone: 7.6.1

comment:6 Changed 6 years ago by pcapriotti

difficulty: Unknown
Owner: set to pcapriotti

Changed 6 years ago by pcapriotti

Attachment: 5527.patch added

comment:7 Changed 6 years ago by pcapriotti

Status: newpatch

If I understand correctly, the actual error here is in user code (setContext should be called with an IIDecl instead of an IIModule), and the timestamp-related issue is gone (the example now fails consistently).

The only remaining problem is the cryptic error message, which should be improved by the attached patch.

comment:8 Changed 6 years ago by simonmar

pcapriotti: your patch looks ok to me, go ahead.

comment:9 Changed 6 years ago by p.capriotti@…

commit b8e0074794e085fdc2271f39aec92a0b472c6b46

Author: Paolo Capriotti <>
Date:   Wed Jun 6 15:24:21 2012 +0100

    Better error messages for setContext (#5527).
    Make InteractiveEval.setContext throw a clearer exception when it is
    asked to add an IIModule which is not a home module or is not

 compiler/main/InteractiveEval.hs |   35 +++++++++++++++++++++++------------
 1 files changed, 23 insertions(+), 12 deletions(-)

comment:10 Changed 6 years ago by pcapriotti

Resolution: fixed
Status: patchclosed
Note: See TracTickets for help on using tickets.