Opened 19 months ago

Closed 4 months ago

Last modified 4 months ago

#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:

Description

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-0.4.0.2 failed during the building phase. The exception was:

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

Change History (15)

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

Okay, success.

*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: 
  GHC.List.CAF
  --> 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 19 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 19 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 19 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 19 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 19 months ago by thoughtpolice

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

Merged.

comment:10 Changed 4 months ago by ezyang

  • Owner nomeata deleted
  • Resolution fixed deleted
  • Status changed from closed to new

After adjusting the test-case to not do a direct import of the hs-boot file, I now get this Core Lint error:

Compile failed (status 256) errors were:
*** Core Lint errors : in result of Simplifier ***
T8743.hs-boot:3:10: warning:
    [RHS of $fxToRowMaybe :: forall a_anp. ToRow (Maybe a_anp)]
    idArity 1 exceeds typeArity 0: $fxToRowMaybe
*** Offending Program ***
$ctoRow_awT :: forall a_awR. Maybe a_awR -> [()]
[LclId,
 Arity=1,
 Str=DmdType,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True,
         WorkFree=True, Expandable=True,
         Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}]
$ctoRow_awT =
  \ (@ a_awR) (ds_dx0 :: Maybe a_awR) ->
    case ds_dx0 of _ [Occ=Dead] { __DEFAULT -> : @ () () ([] @ ()) }

$fToRowMaybe [InlPrag=INLINE (sat-args=0)]
  :: forall a_awP. ToRow (Maybe a_awP)
[LclIdX[DFunId(nt)],
 Arity=1,
 Str=DmdType,
 Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True,
         WorkFree=True, Expandable=True,
         Guidance=ALWAYS_IF(arity=0,unsat_ok=False,boring_ok=True)
         Tmpl= $ctoRow_awT
               `cast` (forall a_awR. Sym (NTCo:ToRow[0] <Maybe a_awR>_N)
                       :: (forall a_awR. Maybe a_awR -> [()])
                          ~R# (forall a_awR. ToRow (Maybe a_awR)))}]
$fToRowMaybe =
  $ctoRow_awT
  `cast` (forall a_awR. Sym (NTCo:ToRow[0] <Maybe a_awR>_N)
          :: (forall a_awR. Maybe a_awR -> [()])
             ~R# (forall a_awR. ToRow (Maybe a_awR)))

$fxToRowMaybe :: forall a_anp. ToRow (Maybe a_anp)
[LclIdX,
 Arity=1,
 Str=DmdType,
 Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True,
         WorkFree=True, Expandable=True,
         Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}]
$fxToRowMaybe = $fToRowMaybe

*** End of Offense ***

Do not know enough to investigate further.

comment:11 Changed 4 months ago by ezyang

You can get the new test-case by applying https://phabricator.haskell.org/D860

comment:12 Changed 4 months ago by ezyang

  • Owner set to nomeata

comment:13 Changed 4 months ago by nomeata

I’m confused. The harbormaster build for Phab:D860 at https://phabricator.haskell.org/harbormaster/build/3863/ does not list 8743 as failing.

Also, this looks like a different bug, unrelated to the demand analyzer, and related to the lint check introduced in #10181. I suggest to discuss this in a separate ticket.

Also feel free to go ahead with your patches, marking the test case as expect_broken.

comment:14 Changed 4 months ago by nomeata

I indeed was confused. The test is already marked as expect_broken, and you are trying to fix the breakage... But it still is unrelated to the demand analyzer. I’ll continue the discussion in #10182, where it belongs.

comment:15 Changed 4 months ago by nomeata

  • Resolution set to fixed
  • Status changed from new to closed
Last edited 4 months ago by nomeata (previous) (diff)
Note: See TracTickets for help on using tickets.