Opened 3 years ago

Last modified 21 months ago

#9046 new bug

Panic in GHCi when using :print

Reported by: quchen Owned by:
Priority: normal Milestone:
Component: GHCi Version: 7.8.2
Keywords: Cc: hvr
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHCi crash Test Case: tests/ghci.debugger/scripts/print036
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


When using names generated by :print, GHCi panics sometimes. According to #ghc, this is reproducible on x86_64-apple-darwin as well, but is not an issue in 7.6.3 x86_64 linux.

> let a = [1]

> :print a
a = (_t1::Num t => [t])

> :t _t1
ghc: panic! (the 'impossible' happened)
  (GHC version 7.8.2 for x86_64-unknown-linux):
	tcTyVarDetails t{tv avD} [tv]

> _t1
<same panic>

From playing around with it a bit, this seems to have something to do with polymorphic values.

-- No panic
> let a = [1 :: Int]
> let a = 1 :: Int
> let a = "hello"

-- Panic
> let a = [1]
> let a = 1
> let a = "hello" -- With -XOverloadedStrings

Attachments (1)

0001-Add-test-case-for-9046.patch (1.8 KB) - added by bravit 3 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 3 years ago by chris.parks

I'm seeing the same thing on x86_64-apple-darwin in GHC HEAD:

> :t _t1
ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 7.9.20140520 for x86_64-apple-darwin):
	ASSERT failed! file compiler/typecheck/TcType.lhs line 640 t

That ASSERT is in isMetaTyVar:

isMetaTyVar tv
   = ASSERT2( isTcTyVar tv, ppr tv )
       case tcTyVarDetails tv of
         MetaTv {} -> True
         _         -> False

We're expecting that tv was constructed by the TcTyVar constructor of the Var datatype. However, what little printf-debugging I've been able to do indicates that we're getting a plain TyVar instead. Maybe someone with more debugging experience can shed some light on this?

comment:2 Changed 3 years ago by thoughtpolice


Moving to 7.8.4.

comment:3 Changed 3 years ago by archblob

For :info _t1 we get:

WARNING: file compiler/main/PprTyThing.hs, line 153 _t1
_t1 :: Num t => [t] 	-- Defined at <no location info>

comment:4 Changed 3 years ago by bravit

Another strange result made visible using -fprint-explicit-foralls:

$ ghci -fprint-explicit-foralls
GHCi, version 7.8.2:  :? for help

> let a = [1]

> :print a
a = (_t1::Num t => [t])

> :show bindings
a :: forall t. Num t => [t] = _
_t1 :: Num t => [t] = _

It looks like free type variable t in the signature of _t1 causes GHC panic while typechecking it. Although I can't figure out whether it is a bug of rtti type reconstruction in :print or incorrect behaviour during typechecking.

Last edited 3 years ago by bravit (previous) (diff)

comment:5 Changed 3 years ago by bravit

No problem for unbounded polymorphic type variable:

$ ghci -fprint-explicit-foralls
GHCi, version 7.8.2:  :? for help

> :t length
length :: forall a. [a] -> Int

> :print length
length = (_t1::[a] -> Int)

> :t _t1
_t1 :: [a] -> Int


> :t read
read :: forall a. Read a => String -> a

> :print read
read = (_t2::Read a1 => String -> a1)

> :t _t2
ghc: panic! (the 'impossible' happened)
  (GHC version 7.8.2 for x86_64-unknown-linux):
        tcTyVarDetails a1{tv asM} [tv]

comment:6 Changed 3 years ago by bravit

We had different behaviour for :print back in 7.6.3:

$ ghci -fprint-explicit-foralls
GHCi, version 7.6.3:  :? for help

> :print read
read = (_t1::forall a. Read a => String -> a)
> :t _t1
_t1 :: forall a. Read a => String -> a

> :print length
length = (_t2::forall a. [a] -> Int)
> :t _t2
_t2 :: forall a. [a] -> Int

comment:7 Changed 3 years ago by bravit

All right, removing of enclosing foralls during :print was intentional according to this commit:

In a8ac471d435214dbdc1fa70f938c63128993a1db/ghc: Fix the deugger (fixing Trac #8557)

The runtime debugger (which has not received any love from anyone for many years) looks wrong to me; it was failing to instantiate the outer foralls of a variable when called from :force, which calls cvObtainTermFromId, which calls cvObtainTerm

I simplified the code too. But I'm flaky on how this debugger stuff is really supposed to work, so I'm partly guessing. Tests pass though.

SPJ particularly wrote in compiler/ghci/RtClosureInspect.hs:

+-- Generalize the type: find all free and forall'd tyvars
 +-- and return them, together with the type inside, which
 +-- should not be a forall type.

So now it looks like typechecking issue with free bounded polymorphic tyvars: free type variable is built by TyVar constructor of Var and it stays the same during typechecking. In the presence of constraints (if tyvar is bounded) we try to solve them and then get this GHC panic: we need TcTyVar constructor there.

I suppose solution could be to replace free tyvar with TcTyVar before solving constraints though I need some guidance to implement it.

Changed 3 years ago by bravit

comment:8 Changed 3 years ago by bravit

Status: newpatch

comment:9 Changed 3 years ago by Austin Seipp <austin@…>

In defc42e7dfdcc0685077ef3dc8bea6b80e2a66dc/ghc:

Add test case for #9046

Signed-off-by: Austin Seipp <>

comment:10 Changed 3 years ago by thoughtpolice

Status: patchnew
Test Case: tests/ghci.debugger/scripts/print036

comment:11 Changed 3 years ago by francesquini

Same problem, different steps:

GHCi, version 7.8.3:  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> let x = 3 + 4
Prelude> :print x
x = (_t1::Num a => a)
Prelude> :force x
x = _
Prelude> print _t1
ghc: panic! (the 'impossible' happened)
  (GHC version 7.8.3 for x86_64-unknown-linux):
    tcTyVarDetails a{tv atm} [tv]

comment:12 Changed 3 years ago by simonpj

This is clearly a bug. (All panics are, really.) And hence embarrassing to have open for so long. But I didn't write the code for the GHCi debugger, and I only partly understand it. It needs love and care from someone. At the moment this ticket is sitting in my "look at this when I have time" pile, but I never have time.

It would be great if someone was willing to take the time to dig into how the debugger works, and maybe "own" it for the future. The good thing is that it's only one or two modules, and there are few non-local ramifications, so it's a well-contained collection of issues.

Also, this ticket a show-stopper for anyone?


comment:13 Changed 3 years ago by thoughtpolice


Moving (in bulk) to 7.10.4

comment:14 Changed 3 years ago by thoughtpolice


Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:15 Changed 2 years ago by thoughtpolice


Milestone renamed

comment:16 Changed 21 months ago by thomie

Milestone: 8.0.1
Note: See TracTickets for help on using tickets.