Opened 3 years ago

Closed 23 months 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 Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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 3 years ago.
Test case
5527.patch (4.0 KB) - added by pcapriotti 23 months ago.

Download all attachments as: .zip

Change History (12)

Changed 3 years ago by cdsmith

Test case

comment:1 Changed 3 years ago by cdsmith

  • Architecture changed from Unknown/Multiple to x86
  • Operating System changed from Unknown/Multiple to Linux

comment:2 Changed 3 years ago by simonpj

See this thread for more details: http://www.haskell.org/pipermail/glasgow-haskell-users/2011-October/020975.html, including various situations in which the bug does or does not manifest itself.

comment:3 Changed 3 years ago by simonmar

Plan:

  • 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 3 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 2 years ago by igloo

  • Milestone set to 7.6.1

comment:6 Changed 2 years ago by pcapriotti

  • Difficulty set to Unknown
  • Owner set to pcapriotti

Changed 23 months ago by pcapriotti

comment:7 Changed 23 months ago by pcapriotti

  • Status changed from new to patch

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 23 months ago by simonmar

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

comment:9 Changed 23 months ago by p.capriotti@…

commit b8e0074794e085fdc2271f39aec92a0b472c6b46

Author: Paolo Capriotti <p.capriotti@gmail.com>
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
    interpreted.

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

comment:10 Changed 23 months ago by pcapriotti

  • Resolution set to fixed
  • Status changed from patch to closed
Note: See TracTickets for help on using tickets.