Opened 7 months ago

Closed 7 months ago

Last modified 6 months ago

#8603 closed bug (fixed)

GHC crashes on some code using StateT monad transformer

Reported by: person1729 Owned by:
Priority: normal Milestone:
Component: Compiler (Type checker) Version: 7.6.3
Keywords: Cc:
Operating System: MacOS X Architecture: x86_64 (amd64)
Type of failure: Compile-time crash Difficulty: Unknown
Test Case: typecheck/should_fail/T8603 Blocked By:
Blocking: Related Tickets:


GHC version 7.6.3 on Mac OS X 10.9 crashes with the following message when compiling the attached file:

ghc -c -v3 -dcore-lint  DiscreteRandomVariableST.hs
Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.4.2
Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/package.conf.d/package.cache
Using binary package database: /Users/***/.ghc/x86_64-darwin-7.6.3/package.conf.d/package.cache
hiding package binary- to avoid conflict with later version binary-
hiding package Cabal-1.16.0 to avoid conflict with later version Cabal-
wired-in package ghc-prim mapped to ghc-prim-
wired-in package integer-gmp mapped to integer-gmp-
wired-in package base mapped to base-
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags: -static
Created temporary directory: /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0
*** C pre-processor:
'/sw/bin/gcc-4' '-E' '-undef' '-traditional' '-m64' '-fno-stack-protector' '-m64' '-I' '/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/base-' '-I' '/Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/include' '-D__GLASGOW_HASKELL__=706' '-Ddarwin_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Ddarwin_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-U __PIC__' '-D__PIC__' '-x' 'c' 'DiscreteRandomVariableST.hs' '-o' '/var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0/ghc13041_0.hscpp'
*** Checking old interface for main:DiscreteRandomVariableST:
*** Parser:
*** Renamer/typechecker:

    Couldn't match kind `* -> *' with `*'
    Expected type: [t1] -> StateT s RV t0
      Actual type: [t1] -> StateT s RV t0
    Kind incompatibility when matching types:
      [t_t14] :: * -> *
      [t1] :: *
    The function `lift'*** Deleting temp files:
Deleting: /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0/ghc13041_0.s /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0/ghc13041_0.hscpp
Warning: deleting non-existent /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0/ghc13041_0.s
*** Deleting temp dirs:
Deleting: /var/folders/dg/lby0mtps13l9g0lry_dhsv1c0000gn/T/ghc13041_0
ghc: panic! (the 'impossible' happened)
  (GHC version 7.6.3 for x86_64-apple-darwin):
	kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}

Please report this as a GHC bug:}}}

Attachments (1)

DiscreteRandomVariableBugReport.hs (682 bytes) - added by person1729 7 months ago.
Test case

Download all attachments as: .zip

Change History (8)

Changed 7 months ago by person1729

Test case

comment:1 Changed 7 months ago by Simon Peyton Jones <simonpj@…>

In 8721743e88f4c8c385eb0ceb0ca6804b2143a8fa/ghc:

Re-factor TcCanonical (again), fixes Trac #8603

This is a substantial refactoring of the canonicaliser. The proximate
cause was that we were sometimes failing to correctly orient a
tyvar/tyvar equality (x ~ y), because the kind of x or y was not fully
zonked at the moment we compared them.  That in turn led me to look
closely at the way that canEvNC (which decomposes equalities) worked.

* The big change is that the 'reOrient' and 'classify' functions are gone,
  along with classify's 'TypeClassifier' return type.  Instead the
  re-orientation is built into canEqNC.  When we find a type variable
  we divert into canEqTyVar, and so on, very much as in TcUnify.

* TcCanonical.canEqTyVar, canEqLeafFun, etc now carry a SwapFlag (to
  reduce duplication), just as in TcUnify; now SwapFlag itself is
  defined in BasicTypes

* I renamed TcSMonad.rewriteCtFlavor to rewriteEvidence,

* I added a new specialised version of rewriteEvidence, called
  TcSMonad.rewriteEqEvidence.  It is easier to use, and removes
  the crafty but brain-mangling higher order casts that we were
  using before.

The result is not exactly simpler, but it's pretty clear and, I think,
significantly more efficient.  And it fixes Trac #8603!

comment:2 Changed 7 months ago by Simon Peyton Jones <simonpj@…>

comment:3 Changed 7 months ago by simonpj

  • Resolution set to fixed
  • Status changed from new to closed
  • Test Case changed from Attached to typecheck/should_fail/T8603

Thanks for identifying this bug!


comment:4 Changed 6 months ago by monoidal

I don't understand completely what's going on here, but in your program lift uniform [1,2,3] should be lift (uniform [1,2,3]). This makes it compile under GHC 7.6. (I thought this error had long already been fixed in 7.7. Strange.)

comment:5 Changed 6 months ago by simonpj

The point is that a type-incorrect program made GHC crash. That shouldn't happen, and that's what I fixed. Making the program itself right is another matter, as you point out.


comment:6 Changed 6 months ago by monoidal

What confuses me is that before the commit 7.7 already did not crash for this program. I checked that a6f6169a9939525c859b274955e8606d6080100f (commit just before yours) and HEAD give the same error message. Was the commit just internal refactoring, or has it visible consequences?

comment:7 Changed 6 months ago by simonpj

Well that is puzzling. I was sure I saw HEAD crash with kindFunResult panic.

Anyway, regardless the refactoring is a good thing, I think. There really was a bug before.


Note: See TracTickets for help on using tickets.