Opened 19 months ago

Last modified 3 months ago

#9046 new bug

Panic in GHCi when using :print

Reported by: quchen Owned by:
Priority: normal Milestone: 8.0.1
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 17 months ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 19 months 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 18 months ago by thoughtpolice

  • Milestone changed from 7.8.3 to 7.8.4

Moving to 7.8.4.

comment:3 Changed 18 months 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 18 months 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 18 months ago by bravit (previous) (diff)

comment:5 Changed 18 months 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 18 months 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 18 months 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 17 months ago by bravit

comment:8 Changed 17 months ago by bravit

  • Status changed from new to patch

comment:9 Changed 16 months ago by Austin Seipp <austin@…>

In defc42e7dfdcc0685077ef3dc8bea6b80e2a66dc/ghc:

Add test case for #9046

Signed-off-by: Austin Seipp <[email protected]>

comment:10 Changed 16 months ago by thoughtpolice

  • Status changed from patch to new
  • Test Case set to tests/ghci.debugger/scripts/print036

comment:11 Changed 14 months 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 14 months 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 14 months ago by thoughtpolice

  • Milestone changed from 7.8.4 to 7.10.1

Moving (in bulk) to 7.10.4

comment:14 Changed 11 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.12.1

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 3 months ago by thoughtpolice

  • Milestone changed from 7.12.1 to 8.0.1

Milestone renamed

Note: See TracTickets for help on using tickets.