Opened 10 years ago

Closed 9 years ago

#3787 closed bug (fixed)

GHC 6.12.1 panic

Reported by: blamario Owned by: simonpj
Priority: normal Milestone: 7.0.1
Component: Compiler (Type checker) Version: 6.12.1
Keywords: panic Cc:
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Compile-time crash Test Case: indexed-types/should_compile/T3787
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by simonmar)

GHC 6.12.1 reports the following when compiling the attached module:

$ ghc --make Trampoline.hs -O[1 of 1] Compiling Control.Concurrent.SCC.Trampoline ( Trampoline.hs, Trampoline.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 6.12.1 for x86_64-unknown-linux):
	expectJust chooseExternalIds: ds_d1HQ

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

So I'm dutifully reporting it. The module in question could probably be easily trimmed down, but I'm too sleepy at the moment. Let me know if you need that.

Attachments (3)

Trampoline.hs (24.9 KB) - added by blamario 10 years ago.
The module that's causing all the panic
Trampoline-small.hs (1.9 KB) - added by ajd 10 years ago.
Trimmed down file that causes the bug.
Trampoline.2.hs (26.5 KB) - added by blamario 10 years ago.
A newer version of the module, with a more thorough panic.

Download all attachments as: .zip

Change History (18)

Changed 10 years ago by blamario

Attachment: Trampoline.hs added

The module that's causing all the panic

comment:1 Changed 10 years ago by ajd

This also happens on i686. Note that it only happens with optimizations enabled (-O or -O2).

I trimmed down the module as much as I could while preserving the bug; I'll attach the result. Note that removing the type signature or any of the cases of resolveProducerConsumer makes the bug go away: all four must be present to cause the panic.

Changed 10 years ago by ajd

Attachment: Trampoline-small.hs added

Trimmed down file that causes the bug.

comment:2 Changed 10 years ago by simonmar

Description: modified (diff)
Milestone: 6.12.2
Owner: set to simonmar
Priority: normalhigh

I'll look at this, probably my fault as I modified chooseExternalIds last.

comment:3 Changed 10 years ago by blamario

I found a slightly different way to panic. This one is more bothersome because it occurs when I try compiling (what I hope is) a correct and usable module. Furthermore, the panic happens with or without optimization. Even GHCi panics, though not when it loads the module but later, when I try to run tests.

Here's what I get:

$ ghc --make Test.hs -o test -threaded -hidir obj -odir obj
[1 of 8] Compiling Control.Concurrent.SCC.Trampoline ( Control/Concurrent/SCC/Trampoline.hs, obj/Control/Concurrent/SCC/Trampoline.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 6.12.1 for x86_64-unknown-linux):
	initC: srt_lbl

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

$ 
$ ghci '*Test'
GHCi, version 6.12.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 8] Compiling Control.Concurrent.SCC.Trampoline ( Control/Concurrent/SCC/Trampoline.hs, interpreted )
[2 of 8] Compiling Control.Concurrent.SCC.Types ( Control/Concurrent/SCC/Types.hs, interpreted )
[3 of 8] Compiling Control.Concurrent.SCC.Combinators ( Control/Concurrent/SCC/Combinators.hs, interpreted )
[4 of 8] Compiling Control.Concurrent.SCC.Primitives ( Control/Concurrent/SCC/Primitives.hs, interpreted )
[5 of 8] Compiling Control.Concurrent.SCC.XML ( Control/Concurrent/SCC/XML.hs, interpreted )
[6 of 8] Compiling Control.Concurrent.Configuration ( Control/Concurrent/Configuration.hs, interpreted )
[7 of 8] Compiling Control.Concurrent.SCC.Components ( Control/Concurrent/SCC/Components.hs, interpreted )
[8 of 8] Compiling Main             ( Test.hs, interpreted )
Ok, modules loaded: Main, Control.Concurrent.Configuration, Control.Concurrent.SCC.Trampoline, Control.Concurrent.SCC.Types, Control.Concurrent.SCC.Combinators, Control.Concurrent.SCC.Components, Control.Concurrent.SCC.XML, Control.Concurrent.SCC.Primitives.
*Main> main
Loading package syb-0.1.0.2 ... linking ... done.
Loading package base-3.0.3.2 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package time-1.1.4 ... linking ... done.
Loading package random-1.0.0.2 ... linking ... done.
Loading package QuickCheck-1.2.0.0 ... linking ... done.
Loading package array-0.3.0.0 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package mtl-1.1.0.2 ... linking ... done.
Loading package parallel-1.1.0.1 ... linking ... done.
ghc: panic! (the 'impossible' happened)
  (GHC version 6.12.1 for x86_64-unknown-linux):
	nameModule ds_d1YX{v}

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

I'll attach the modified module. It still contains lots of irrelevant code, but it should be easy to trim. To reproduce the GHCi panic, you'll need to get the current code from the Darcs repository at http://code.haskell.org/SCC/ and then replace the Control.Concurrent.SCC.Trampoline module by the attached one.

Changed 10 years ago by blamario

Attachment: Trampoline.2.hs added

A newer version of the module, with a more thorough panic.

comment:4 Changed 10 years ago by blamario

It might be worth a mention that GHC 6.10.4 gives exactly the same results.

comment:5 Changed 10 years ago by simonpj

Thank you for boiling this down. If you compile with -dcore-lint you'll see that the typechecker is constructing an ill-typed program. I'm not sure why yet.

I don't know whether that is the cause of the nameModule error, but I suppose it could be.

As it happens I plan to work on the type-inference engine (and the constraint solver in particular) over the next two or three months, so I'll fix it as part of that sweep.

Meanwhile, the problem is associated with contexts that have equalities in them, eg:

resolveProducerConsumer 
  :: forall a s s0 t t' m x.
     (Functor s0, Monad m, s ~ SomeFunctor (TryYield a) (Await (Maybe a)),
      t ~ Trampoline (EitherFunctor s0 s) m x) =>
     s t -> t

You can get rid of these easily by replacing s by (SomeFunctor (TryYield a) (Await (Maybe a))), and similarly for t. I tried this, and it worked.

Meanwhile I'll keep the test -- thank you!

Simon

comment:6 Changed 10 years ago by simonmar

Owner: changed from simonmar to simonpj

comment:7 Changed 10 years ago by simonmar

Component: CompilerCompiler (Type checker)
Milestone: 6.12.26.14.1
Priority: highnormal

This bug is something that we plan to fix in 6.14.1 with the new type inference engine, and there's a workaround for 6.12.

comment:8 Changed 9 years ago by igloo

Blocked By: 4232 added

comment:9 Changed 9 years ago by simonpj

Status: newinfoneeded
Test Case: indexed-types/should_compile/T3787

OK Trampoline-small.hs is now fine. So I believe that the new type checker has fixed the problem.

Can you try on your main example with the HEAD (or with the release candidate we put out at the end of next week)?

I'll move the ticket to 'infoneeded'

I've added your code the the regression suite.

Thanks

Simon

comment:10 Changed 9 years ago by blamario

test

comment:11 Changed 9 years ago by blamario

I've tested the original test case with HEAD from 2010-09-15, and there's no panic any more. I guess the bug can be closed. The only thing I find mildly alarming is that the module doesn't compile with HEAD, while it compiles with GHC 6.12.1. Even the current version of SCC doesn't compile with HEAD. Is this a known problem or should I be worried? Here is the error message I get on the current version of SCC from Darcs repository at http://code.haskell.org/SCC/:

Control/Concurrent/SCC/Streams.hs:387:28:
    Couldn't match type `d' with `d1'
      because this skolem type variable would escape: `d1'
    This skolem is bound by
      the polymorphic type
      `forall (d :: * -> *).
       AncestorFunctor a d =>
       Int -> Coroutine d m [x]'
    The following variables have types that mention d
      repeat :: Int -> Coroutine d m [y]
        (bound at Control/Concurrent/SCC/Streams.hs:388:10)
    In the `getChunk' field of a record
    In the expression: Source {getChunk = repeat}
    In an equation for `retryWhileEmpty':
        retryWhileEmpty f source
          = Source {getChunk = repeat}
          where
              repeat n
                = getChunk source n >>= apply
                where
                    apply input = test input =<< f input
                    test (_ : _) [] = repeat n
                    test _ output = return output

comment:12 Changed 9 years ago by simonpj

For reasons described in "Let should not be generalised" GHC doesn't generalise local let bindings, at least not when you are using GADTs. That can give rise to skolem escape checks like you see.

The fix is to add a type signature for your local definition; in this case you probably want a type signature for 'repeat'. Does that fix it?

Simon

comment:13 Changed 9 years ago by blamario

I added the type signature and the module now compiles. Thanks.

comment:14 Changed 9 years ago by simonpj

Resolution: fixed
Status: infoneededclosed

comment:15 Changed 9 years ago by igloo

Blocked By: 4232 removed
Note: See TracTickets for help on using tickets.