Opened 5 years ago

Closed 5 years ago

#2898 closed merge (fixed)

crash when interpreting

Reported by: nolrai Owned by: igloo
Priority: normal Milestone:
Component: Compiler Version: 6.10.1
Keywords: Cc:
Operating System: Linux Architecture: x86
Type of failure: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description (last modified by simonpj)

when I interpret my file Utilities/ChoiceMonad?.hs from ghci-haskline I get the following message:

[2 of 2][Compiling Utilities.ChoiceMonad ( Utilities/ChoiceMonad.hs, interpreted )
ghci-haskeline: panic! (the 'impossible' happened)
  (GHC version 6.10.1 for i386-unknown-linux):
	ByteCodeGen.schemeE: unhandled case
    \ (@ a1{tv a1qQ} [sk] :: ghc-prim:GHC.Prim.*{(w) tc 34d})
      (@ b1{tv a1qR} [sk] :: ghc-prim:GHC.Prim.*{(w) tc 34d}) ->
      case {tick (main:Utilities.ChoiceMonad, 169)}{v d1z7} [gid]
             @ (ghc-prim:GHC.Prim.State#{(w) tc 32q}
                  ghc-prim:GHC.Prim.RealWorld{(w) tc 31E})
      {(a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk])
       -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw}
            m{tv aQH} [sk] a1{tv a1qQ} [sk]
       -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw}
            m{tv aQH} [sk] b1{tv a1qR} [sk]}
      of (tick{v s29j} [lid] :: ghc-prim:GHC.Prim.State#{(w) tc 32q}
                                  ghc-prim:GHC.Prim.RealWorld{(w) tc 31E})
      { __DEFAULT ->
      let {
        sat_s20H{v} [lid] :: (a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk])
                             -> main:Utilities.LeafyTree.LeafyTree{tc rfw} a1{tv a1qQ} [sk]
                             -> main:Utilities.LeafyTree.LeafyTree{tc rfw} b1{tv a1qR} [sk]
        []
        sat_s20H{v} [lid] =
          base:GHC.Base.fmap{v r5G} [gid]
            @ main:Utilities.LeafyTree.LeafyTree{tc rfw}
            main:Utilities.LeafyTree.$f4{v rfq} [gid]
            @ a1{tv a1qQ} [sk]
            @ b1{tv a1qR} [sk] } in
      let {
        sat_s20F{v} [lid] :: (main:Utilities.LeafyTree.LeafyTree{tc rfw}
                                a1{tv a1qQ} [sk]
                              -> main:Utilities.LeafyTree.LeafyTree{tc rfw} b1{tv a1qR} [sk])
                             -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw}
                                  m{tv aQH} [sk] a1{tv a1qQ} [sk]
                             -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw}
                                  m{tv aQH} [sk] b1{tv a1qR} [sk]
        []
        sat_s20F{v} [lid] =
          main:Utilities.ChoiceMonad.inChoiceT{v rLn} [gid]
            @ m{tv aQH} [sk]
            @ a1{tv a1qQ} [sk]
            @ b1{tv a1qR} [sk]
            $dMonad1{v s20D} [lid] } in
      base:GHC.Base..{v r4k} [gid]
        @ (main:Utilities.LeafyTree.LeafyTree{tc rfw} a1{tv a1qQ} [sk]
           -> main:Utilities.LeafyTree.LeafyTree{tc rfw} b1{tv a1qR} [sk])
        @ (main:Utilities.ChoiceMonad.ChoiceT{tc rJw}
             m{tv aQH} [sk] a1{tv a1qQ} [sk]
           -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw}
                m{tv aQH} [sk] b1{tv a1qR} [sk])
        @ (a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk])
        sat_s20F{v} [lid]
        sat_s20H{v} [lid]
      }

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

but if i do "ghc --make Utilities/ChoiceMonad?.hs" that works and I can then load it with ghci-haskline, at least until I modify it and need to compile again.

Attachments (2)

ChoiceMonad.hs (6.7 KB) - added by nolrai 5 years ago.
LeafyTree.hs (2.1 KB) - added by nolrai 5 years ago.
needed to compile other file

Download all attachments as: .zip

Change History (5)

Changed 5 years ago by nolrai

Changed 5 years ago by nolrai

needed to compile other file

comment:1 Changed 5 years ago by simonpj

  • Description modified (diff)
  • Difficulty set to Unknown
  • Owner set to simonpj

Excellent report thank you. What's happening is that CorePrep find an application of a strict function

  f (/\a. blah) ...

and transforms it to this:

  case (/\a. blah) of { DEFAULT -> ... }

If there had been a value lambda, then mkLocalNonRec would have generated a let, not a case. The unexpected type lambda confuses the code generator.

In fact, since all code generators simply ignore type lambdas, there is no reason to disallow them, unlike value lambdas which are supposed to occur only on the RHS of let/recs. So I tidied up ByteCodeGen by systematically using a fucntion bcView (bytecode view) that discards casts, notes, type abstractions, and type applications. Result is shorter, more robust code.

Patch to come.

Simon

comment:2 Changed 5 years ago by simonpj

  • Owner changed from simonpj to igloo
  • Type changed from bug to merge

Fixed by

Tue Dec 30 06:59:48 PST 2008  simonpj@microsoft.com
  * Tidy up treatment of big lambda (fixes Trac #2898)

Pls merge

Simon

comment:3 Changed 5 years ago by igloo

  • Resolution set to fixed
  • Status changed from new to closed

Merged

Note: See TracTickets for help on using tickets.