Opened 5 years ago

Closed 5 years ago

#9426 closed bug (fixed)

ghci triggers 'ASSERT failed! file compiler/ghci/Linker.lhs, line 906'

Reported by: slyfox Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.8.2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: ghci044
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Found by ./validate --slow:

Unexpected failures:
   ghci/scripts  ghci044 [bad stderr] (ghci)
   ghci/scripts  ghci047 [bad stderr] (ghci)

# run manially:
$ LANG=C make fulltest stage=2 TEST="ghci044 ghci047"

=====> ghci047(ghci) 87 of 4083 [0, 1, 0] 
cd ./ghci/scripts && HC='/home/st/fun/ghc/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' '/home/st/fun/ghc/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history     <ghci047.script >ghci047.run.stdout 2>ghci047.run.stderr
Actual stderr output differs from expected:
--- ./ghci/scripts/ghci047.stderr       2014-07-31 12:05:34.000000000 +0300
+++ ./ghci/scripts/ghci047.run.stderr   2014-08-08 16:58:01.000000000 +0300
@@ -1,16 +1,14 @@
+*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 906
+*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 906
 
-<interactive>:38:1:
-    Couldn't match type ‘HFalse’ with ‘HTrue’
-    Expected type: HTrue
-      Actual type: Or HFalse HFalse
-    In the expression: f
-    In the expression: f $ Baz 'a'
-    In an equation for ‘it’: it = f $ Baz 'a'
-
-<interactive>:39:1:
-    Couldn't match type ‘HFalse’ with ‘HTrue’
-    Expected type: HTrue
-      Actual type: Or HFalse HFalse
-    In the expression: f
-    In the expression: f $ Quz
-    In an equation for ‘it’: it = f $ Quz
+<interactive>:36:1: Not in scope: ‘f’
+
+<interactive>:37:1: Not in scope: ‘f’
+
+<interactive>:38:1: Not in scope: ‘f’
+
+<interactive>:39:1: Not in scope: ‘f’
+
+<interactive>:40:1: Not in scope: ‘f’
+
+<interactive>:41:1: Not in scope: ‘f’
Actual stdout output differs from expected:
--- ./ghci/scripts/ghci047.stdout       2014-07-31 12:05:34.000000000 +0300
+++ ./ghci/scripts/ghci047.run.stdout   2014-08-08 16:58:01.000000000 +0300
@@ -1,4 +0,0 @@
-1
-1
-1
-1
*** unexpected failure for ghci047(ghci)

The trigger in compiler/ghci/Linker.lhs:906:

linkSomeBCOs dflags toplevs_only ie ce_in ul_bcos
   = do let nms = map unlinkedBCOName ul_bcos
        hvals <- fixIO
                    ( \ hvs -> let ce_out = extendClosureEnv ce_in (zipLazy nms hvs)
                               in  mapM (linkBCO dflags ie ce_out) ul_bcos )
        let ce_all_additions = zip nms hvals
            ce_top_additions = filter (isExternalName.fst) ce_all_additions
            ce_additions     = if toplevs_only then ce_top_additions
                                               else ce_all_additions
            ce_out = -- make sure we're not inserting duplicate names into the
                     -- closure environment, which leads to trouble.
{- 906 -}            ASSERT(all (not . (`elemNameEnv` ce_in)) (map fst ce_additions))
                     extendClosureEnv ce_in ce_additions
        return (ce_out, hvals)

Change History (4)

comment:1 Changed 5 years ago by slyfox

Suspicious observation:

As in original test case

instance {-# OVERLAPS #-} (HTrue ~ b)  => TypeEq x x b
instance {-# OVERLAPS #-} (HTrue ~ b)  => TypeEq x x b
instance {-# OVERLAPS #-} (HFalse ~ b) => TypeEq x y b

leads to error

*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 912

(the name failing invariant is '$fTypeEqxxb')

If we slightly change free variables:

instance {-# OVERLAPS #-} (HTrue ~ b)  => TypeEq x x b
instance {-# OVERLAPS #-} (HTrue ~ b)  => TypeEq y y b -- changed 'x' to 'y'
instance {-# OVERLAPS #-} (HFalse ~ b) => TypeEq x y b

there is no assert anymore:

Prelude> :script z.script 
WARNING: file compiler/simplCore/SimplEnv.lhs, line 539 $fTypeEqyyb
WARNING: file compiler/simplCore/SimplEnv.lhs, line 539 $fTypeEqxyb
WARNING: file compiler/simplCore/SimplEnv.lhs, line 539 $fTypeEqyyb
WARNING: file compiler/simplCore/SimplEnv.lhs, line 539 $fTypeEqxyb

Looks like some generated names are not unique emough.

Last edited 5 years ago by slyfox (previous) (diff)

comment:2 Changed 5 years ago by slyfox

Test Case: ghci044

comment:3 Changed 5 years ago by Simon Peyton Jones <simonpj@…>

In 67a0cab6b501e2d6280b51655af66ad448b3deef/ghc:

Fix GHCi/GHC-API tidying and modules (Trac #9424, #9426)

There were two related bugs here

Trac #9426
   We must increment the ic_mod_index field of the InteractiveContext
   if we have new instances, because we maek DFunIds that should be
   distinct from previous ones.  Previously we were only incrementing
   when defining new user-visible Ids.

   The main change is in HscTypes.extendInteractiveContext, which now
   alwyas bumps the ic_mod_index.  I also added a specialised
   extendInteractiveContextWithIds for the case where we are *only*
   adding new user-visible Ids.

Trac #9424
   In HscMain.hscDeclsWithLocations we were failing to use the
   *tidied* ClsInsts; but the un-tidied ones are LocalIds which
   causes a later ASSERT error.

   On the way I realised that, to behave consistently, the tcg_insts
   and tcg_fam_insts field of TcGblEnv should really only contain
   instances from the current GHCi command, not all the ones to date.
   That in turn meant I had to move the code for deleting replacement
   instances from addLocalInst, addLocalFamInst to
   HscTypes.extendInteractiveContext

comment:4 Changed 5 years ago by slyfox

Resolution: fixed
Status: newclosed

Looks fixed.

Thank you!

Note: See TracTickets for help on using tickets.