#8743 closed bug (fixed)

The impossible happened : Prelude.(!!): index too large

Reported by: erikd Owned by: nomeata
Priority: highest Milestone: 7.8.1
Component: Compiler Version: 7.8.1-rc1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: x86_64 (amd64)
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:


Running ghc git HEAD (reports it's version as 7.9.20140206) and when cabal installing postgresql-simple I get:

ghc: panic! (the 'impossible' happened)
  (GHC version 7.9.20140206 for x86_64-unknown-linux):
        Prelude.(!!): index too large

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

cabal: Error: some packages failed to install:
postgresql-simple- failed during the building phase. The exception was:

postgresql-simple- installs fine with 7.6.3. I'm going to compile 7.8-rc1 and see if the same problem exists there.

Change History (9)

comment:1 Changed 15 months ago by erikd

  • Milestone set to 7.8.1
  • Priority changed from normal to highest

Same problem for 7.8-rc1 on amd64 Linux (Debian Testing).

comment:2 Changed 15 months ago by goldfire

I have a terrible feeling this one is my fault. (I wrote code using !! in TcIface.) But I can't build HEAD (see #8744) to find out.

comment:3 Changed 15 months ago by rwbarton

I'm trying to massage GHC into giving me a proper stack trace (with -xc) but for now I can tell you the exception occurs somewhere inside WorkWrap.splitFun. (Which doesn't use !! directly, naturally...)

comment:4 Changed 15 months ago by rwbarton

Okay, success.

*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: 
  --> evaluated by: WwLib.deepSplitCprType_maybe.con,
  called from WwLib.mkWWcpr,
  called from WwLib.mkWwBodies,
  called from WorkWrap.splitFun,
  called from WorkWrap.splitFun,
  called from WorkWrap.tryWW.doSplit,
  called from WorkWrap.wwBind,
  called from WorkWrap.wwTopBinds,
  called from WorkWrap.wwTopBinds,
  called from UniqSupply.initUs_,
  called from WorkWrap.wwTopBinds,
  called from WorkWrap.wwTopBinds,
  called from SimplCore.doPassDFU,
  called from ...

The offending code is

deepSplitCprType_maybe fam_envs con_tag ty
  | let (co, ty1) = topNormaliseType_maybe fam_envs ty
                    `orElse` (mkReflCo Representational ty, ty)
  , Just (tc, tc_args) <- splitTyConApp_maybe ty1
  , isDataTyCon tc
  , let cons = tyConDataCons tc
        con = ASSERT( cons `lengthAtLeast` con_tag ) cons !! (con_tag - fIRST_TAG)
  = Just (con, tc_args, dataConInstArgTys con tc_args, co)

comment:5 Changed 15 months ago by nomeata

  • Owner set to nomeata

Thanks for the debugging, that is very helpful. It is likely a problem caused by the demand analyser ignoring coercions, so sometimes the type do not match up; in that the solution will be to just make the code more forgiving.

Will look into it later today.

comment:6 Changed 15 months ago by Joachim Breitner <mail@…>

In c3ff5f29c80680a09c7779aee2535fa64b880cd9/ghc:

Add test case for #8743

which only occurs when the instance being compiled is also present from
a .hs-boot file.

comment:7 Changed 15 months ago by Joachim Breitner <mail@…>

In 312686c172eefb74237c8a61e2cca1b2af7459c1/ghc:

In deepSplitCprType_maybe, be more forgiving

the ConTag may be out of range (e.g. if the type constructor is imported
via SOURCE and we don't know any of its data constructors); just return
Nothing without complaining in that case. This fixes #8743.

comment:8 Changed 15 months ago by nomeata

  • Status changed from new to merge

Test case added and the obvious fix applied; please merge to 7.8.

comment:9 Changed 14 months ago by thoughtpolice

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


Note: See TracTickets for help on using tickets.