Ticket #1716 (closed bug: fixed)

Opened 1 year ago

Last modified 9 months ago

panic when running program from GHCi

Reported by: g9ks157k@acme.softbase.org Assigned to: chak
Priority: normal Milestone: 6.10 branch
Component: Compiler Version: 6.8
Severity: critical Keywords:
Cc: g9ks157k@acme.softbase.org Difficulty: Unknown
Test Case: Architecture: x86
Operating System: Linux

Description (Last modified by simonpj)

See the reply from Simon which gives a simple stand-alone repro case for this bug. Also fix #1754 first; may be the same thing.

Original report: To reproduce this bug please install GHC 6.8.20070916 and Gtk2Hs 0.9.12 as currently described on http://haskell.org/haskellwiki/Grapefruit#Building. There is a modified version of the development version of Grapefruit attached. Sorry for this large code example but currently I really don’t have the time to reduce this any further.

Please unpack the attached file bug.tar.bz2, enter the directory bug/Haskell and run ghci -cpp -farrows -fth -fglasgow-exts Examples/Simple.hs. Compilation to bytecode should be successful. Then enter main on the GHCi command line. You should get the following messages:

ghc-6.8.0.20070916: panic! (the 'impossible' happened)
  (GHC version 6.8.0.20070916 for i386-unknown-linux):
        nameModule arr{v a85X}

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Attachments

bug.tar.bz2 (23.6 kB) - added by g9ks157k@acme.softbase.org on 09/18/07 12:46:25.
modified version of current Grapefruit development version

Change History

09/18/07 12:46:25 changed by g9ks157k@acme.softbase.org

  • attachment bug.tar.bz2 added.

modified version of current Grapefruit development version

09/18/07 12:49:02 changed by g9ks157k@acme.softbase.org

Note that the file bug.tar.bz2 is different from the file of the same name attached to #1715.

10/16/07 08:39:54 changed by simonpj

  • owner set to chak.
  • description changed.
  • milestone changed from 6.8.1 to 6.10 branch.

Thanks for the report. I'm not certain what the original problem is, but there's a definite bug that show s up when compiling Port.hs on the way to reproducing the bug.

Below is a stand-alone cut-down version that gives a Core Lint error as a result of bogus evidence generation arising from type equalites. I'm changing the milestone to 6.10 (since we are not advertising type equalities for 6.8), and changing the owner to Manuel.

Simon

{-# OPTIONS  -fglasgow-exts #-}
{-# LANGUAGE UndecidableInstances #-}
module Graphics.UI.Grapefruit.Port ( ) where

---------------------------------------
    -- * Type equality
    type family TypeEq type1 type2 :: *

    typeEq :: type1 -> type2 -> TypeEq type1 type2
    typeEq _ _ = undefined

    class Singleton singleton where
        soleValue :: singleton

    class Boolean boolean

    data False

    instance Boolean False

    false :: False
    false = undefined

    data True

    instance Boolean True

    true :: True
    true = undefined

    data headName :& tail = !(Field headName) :& !tail
    infixr 1 :&

    data Field name = !name := Value name
    infix 2 :=

    -- * Names
    class (Singleton name) => Name name where
        type Value name :: *


---------------------------------------
    -- ** Isolation
    class Isolatable record lookupName where
        type Remainder record lookupName :: *

        isolate :: record -> lookupName -> (Field lookupName,Remainder record lookupName)

    instance (IsolatableHelper (TypeEq headName lookupName) headName tail lookupName) =>
             Isolatable (headName :& tail) lookupName where
        type Remainder (headName :& tail) lookupName
            = RemainderHelper (TypeEq headName lookupName) headName tail lookupName

        isolate (headField@(headName := _) :& tail) lookupName
            = isolateHelper (typeEq headName lookupName) headField tail lookupName

    class IsolatableHelper namesAreEqual headName tail lookupName where
        type RemainderHelper namesAreEqual headName tail lookupName :: *

	foo :: tail
        isolateHelper :: namesAreEqual
                      -> Field headName
                      -> tail
                      -> lookupName
                      -> (Field lookupName,RemainderHelper namesAreEqual headName tail lookupName)

    -- On error use lookupName and add (headName ~ lookupName) to the context.
    instance (headName ~ lookupName) =>
             IsolatableHelper True headName tail lookupName where
        type RemainderHelper True headName tail lookupName = tail

        isolateHelper _ headField tail _ = (headField,tail)

10/16/07 08:44:12 changed by simonpj

  • description changed.

12/10/07 23:35:14 changed by chak

  • status changed from new to closed.
  • resolution set to fixed.

Repaired this as part of fixing the GADT regression tests after moving to equality constraints instead of GADT refinement. (Hence, I won't add another test for this problem to the testsuite - there are already at least two in there.)

To be precise, I fixed the standalone problem exhibited by the code in SimonPJ's comment. From what I have seen in similar examples, we get a CoreLint error when compiling with -dcore-lint and a compiler panic without running CoreLint.

12/11/07 01:25:46 changed by simonpj

OK, Grapefruit guys (somehow "g9ks157k" doesn't seem like a catchy name to call you :-), would you like to give the HEAD a whirl on your code? Manuel has fixed the case I boiled out, but maybe you'll find others...

If you find a problem, re-open this bug, or start a new one.

Simon