Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#12843 closed bug (invalid)

Simplifier ticks exhausted When trying UnfoldingDone $

Reported by: MikolajKonarski Owned by:
Priority: normal Milestone:
Component: Compiler Version: 8.0.1
Keywords: Cc:
Operating System: Linux Architecture: Unknown/Multiple
Type of failure: Compile-time crash or panic Test Case:
Blocked By: Blocking:
Related Tickets: #12776 #12789 #12675 Differential Rev(s):
Wiki Page:

Description

[14 of 15] Compiling TieKnot          ( GameDefinition/TieKnot.hs, dist/build/LambdaHack/LambdaHack-tmp/TieKnot.dyn_o )
ghc: panic! (the 'impossible' happened)
  (GHC version 8.0.1 for x86_64-unknown-linux):
	Simplifier ticks exhausted
  When trying UnfoldingDone $
  To increase the limit, use -fsimpl-tick-factor=N (default 100)
  If you need to do this, let GHC HQ know, and what factor you needed
  To see detailed counts use -ddump-simpl-stats
  Total ticks: 8813

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

when compiling in profiling mode the following commit (tons of INLINE and INLINABLE to ensure specialization and a couple more to debug irregularities in the output of the profiler)

https://github.com/LambdaHack/LambdaHack/commit/842070fe78f07e2fb0bce829505dcfa8465ef40f

Steps to reproduce:

1. make configure-prof
2. cabal build

when I instead do

cabal build --ghc-option=-fsimpl-tick-factor=200

it compiles, though when I touch only GameDefinition/Main.hs I always get

~/r/LambdaHack$ cabal build --ghc-option=-fsimpl-tick-factor=200
Building LambdaHack-0.5.1.0...
Preprocessing library LambdaHack-0.5.1.0...
Preprocessing executable 'LambdaHack' for LambdaHack-0.5.1.0...
[15 of 15] Compiling Main             ( GameDefinition/Main.hs, dist/build/LambdaHack/LambdaHack-tmp/Main.dyn_o )
The interface for ‘TieKnot’
Declaration for tieKnot
Unfolding of tieKnot:
  Iface id out of scope:  standardKeys1
[15 of 15] Compiling Main             ( GameDefinition/Main.hs, dist/build/LambdaHack/LambdaHack-tmp/Main.p_o )
The interface for ‘TieKnot’
Declaration for tieKnot
Unfolding of tieKnot:
  Iface id out of scope:  standardKeys1
Linking dist/build/LambdaHack/LambdaHack ...

Change History (14)

comment:1 Changed 3 years ago by MikolajKonarski

Travis suggests that this happens with normal cabal install as well: https://travis-ci.org/LambdaHack/LambdaHack/jobs/176287181

Also, the travis results show this happens with -O0, -O and -O2 and with any recent GHC version, inlcuding as old as 7.8.3.

Due to the extra info, I'm not closing as a duplicate of #12776, #12789 and #12675.

comment:2 Changed 3 years ago by MikolajKonarski

And for this commit --ghc-option=-fsimpl-tick-factor=1000 is not enough, but 10000 is: https://travis-ci.org/LambdaHack/LambdaHack/builds/177586400

comment:3 Changed 3 years ago by simonpj

How exactly do I reproduce this? cabal install lambdahack perhaps?

comment:4 Changed 3 years ago by MikolajKonarski

Nope. The latter snapshot, where 1000 is not enough, is on a branch. You can proceed as in the travis log:

git clone --depth=50 --branch=simplifying-threaded-mode https://github.com/LambdaHack/LambdaHack.git LambdaHack/LambdaHack

To skip gtk2hs, which takes long to compile, try the vty version:

cabal install -fvty

You may want to try with each optimization level in turn, because it was failing with any.

For the original, less excessive, example, try this:

git checkout master
git reset --hard 842070fe78f07e2fb0bce829505dcfa8465ef40f
cabal install -fvty

BTW, thank you for the fix! I wonder if it also fixes the various breakages of INLINE I was reporting in other tickets (https://ghc.haskell.org/trac/ghc/ticket/12603 and its Related Tickets).

comment:5 Changed 3 years ago by simonpj

I wanted to start with HEAD, but I get

Resolving dependencies...
Configuring parsec-3.1.11...
Configuring template-haskell-2.11.0.0...
Building template-haskell-2.11.0.0...
Building parsec-3.1.11...
Failed to install template-haskell-2.11.0.0
Build log ( /home/simonpj/.cabal/logs/template-haskell-2.11.0.0.log ):
cabal: Entering directory '/tmp/cabal-tmp-16852/template-haskell-2.11.0.0'
Configuring template-haskell-2.11.0.0...
Building template-haskell-2.11.0.0...
Preprocessing library template-haskell-2.11.0.0...

Language/Haskell/TH/Lib.hs:487:2: error:
     error: #error Remove deprecated familyNoKindD, familyKindD, closedTypeFamilyNoKindD and closedTypeFamilyKindD
`gcc' failed in phase `C pre-processor'. (Exit code: 1)
cabal: Leaving directory '/tmp/cabal-tmp-16852/template-haskell-2.11.0.0'
Failed to install parsec-3.1.11
Build log ( /home/simonpj/.cabal/logs/parsec-3.1.11.log ):
cabal: Entering directory '/tmp/cabal-tmp-16851/parsec-3.1.11'
Configuring parsec-3.1.11...
Building parsec-3.1.11...
Preprocessing library parsec-3.1.11...
[ 1 of 25] Compiling Text.Parsec.Pos  (.hs -> .o)
[ 2 of 25] Compiling Text.Parsec.Error (.hs -> .o)
[ 3 of 25] Compiling Text.Parsec.Prim (.hs -> .o)
[ 4 of 25] Compiling Text.Parsec.Combinator (.hs -> .o)
[ 5 of 25] Compiling Text.Parsec.Expr (.hs -> .o)
[ 6 of 25] Compiling Text.Parsec.Char (.hs -> .o)
[ 7 of 25] Compiling Text.Parsec.ByteString.Lazy (.hs -> .o)
[ 8 of 25] Compiling Text.Parsec.ByteString (.hs -> .o)
[ 9 of 25] Compiling Text.Parsec      (.hs -> .o)
[10 of 25] Compiling Text.Parsec.Perm (.hs -> .o)
[11 of 25] Compiling Text.Parsec.String (.hs -> .o)
[12 of 25] Compiling Text.Parsec.Text (.hs -> .o)
[13 of 25] Compiling Text.Parsec.Text.Lazy (.hs -> .o)
[14 of 25] Compiling Text.Parsec.Token (.hs -> .o)

Text/Parsec/Token.hs:524:27: error:
    • Could not deduce (Stream s m t0) arising from a use of ‘option’
      from the context: Stream s m Char
        bound by the type signature for:
                   makeTokenParser :: Stream s m Char =>
                                      GenLanguageDef s u m -> GenTokenParser s u m
        at Text/Parsec/Token.hs:(351,1)-(352,63)
      The type variable ‘t0’ is ambiguous
      Relevant bindings include
        decimalFloat :: ParsecT s u1 m (Either Integer Double)
          (bound at Text/Parsec/Token.hs:523:5)
        fractFloat :: forall b a1 u a2.
                      (Read b, Show a2) =>
                      a2 -> ParsecT s u m (Either a1 b)
          (bound at Text/Parsec/Token.hs:528:5)
        fractExponent :: forall a1 u a2.
                         (Show a2, Read a1) =>
                         a2 -> ParsecT s u m a1
          (bound at Text/Parsec/Token.hs:532:5)
        fraction :: forall u. ParsecT s u m [Char]
          (bound at Text/Parsec/Token.hs:546:5)
        exponent' :: forall u. ParsecT s u m [Char]
          (bound at Text/Parsec/Token.hs:552:5)
        int :: forall u. ParsecT s u m Integer
          (bound at Text/Parsec/Token.hs:561:5)
        reservedOp :: String -> ParsecT s u m ()
          (bound at Text/Parsec/Token.hs:590:5)
        (Some bindings suppressed; use -fmax-relevant-binds=N or -fno-max-relevant-binds)
      These potential instances exist:
        instance [safe] Monad m => Stream [tok] m tok
          -- Defined at Text/Parsec/Prim.hs:385:10
        ...plus four instances involving out-of-scope types
        (use -fprint-potential-instances to see them all)
    • In a stmt of a 'do' block: option (Left n) (fractFloat n)
      In the expression:
        do { n <- decimal;
             option (Left n) (fractFloat n) }
      In an equation for ‘decimalFloat’:
          decimalFloat
            = do { n <- decimal;
                   option (Left n) (fractFloat n) }

My HEAD has template-haskell installed, so I'm not sure why it's trying to install a different version. Nor do I understand the error in parsec.

I guess I can try with the 8.0 branch.

comment:6 Changed 3 years ago by simonpj

I'm more worried about the Iface Id out of scope errors, which are outright wrong. How can I reproduce those?

The "ticks-exhausted" thing may be just that there is a lot of inlining going on under library control, and so absolutely fine. Do you have a reason to suppose otherwise?

comment:7 Changed 3 years ago by MikolajKonarski

Regarding HEAD build failures, I have the same problem with TH and HEAD on travis (https://travis-ci.org/LambdaHack/LambdaHack/jobs/177586413). I just ran it with -v2 flag for cabal, to get some more info: https://api.travis-ci.org/jobs/179766413/log.txt?deansi=true

There are some panics there that may be of interest to GHC hackers.

The package template-haskell seems to be required by free-4.12.4 bifunctors-5.4.1 aeson-1.0.2.1 enummapset-th-0.6.1.1 exceptions-0.8.3 functor-infix-0.0.4 tagged-0.8.5

Of these, e.g., https://hackage.haskell.org/package/functor-infix depends on (>=2.8 && <2.12), so that may be the reason for reinstallation.

I don't see the problem with parsec in my log, perhaps because parsec is only needed with the -fvty flag. The travis log above is from a build with no flags (it uses gtk2hs). Yet another option is -fcurses, but it won't help with template-haskell, unfortunately.

comment:8 Changed 3 years ago by MikolajKonarski

Regarding "ticks-exhausted", yes the inlining is excessive and I don't have any reason to suppose anything is amiss, apart of the fact that I need 10 times more ticks than the amount that triggers "panic! (the 'impossible' happened)".

Regarding Iface Id out of scope, I've just reproduced it just as in the original report. Here is a quicker way to reproduce:

Edit: start with git clone https://github.com/LambdaHack/LambdaHack.git and then the following.

git checkout master
git reset --hard 842070fe78f07e2fb0bce829505dcfa8465ef40f
cabal configure
cabal build --ghc-option=-fsimpl-tick-factor=200
touch GameDefinition/Main.hs
cabal build --ghc-option=-fsimpl-tick-factor=200
Last edited 3 years ago by MikolajKonarski (previous) (diff)

comment:9 Changed 3 years ago by simonpj

Thanks. I followed your repro steps above, and it all worked fine... not Iface Id out of scope. Here's the last two steps

simonpj@cam-05-unx:~/tmp/LambdaHack/LambdaHack$  touch GameDefinition/Main.hs
simonpj@cam-05-unx:~/tmp/LambdaHack/LambdaHack$  cabal build --ghc-option=-fsimpl-tick-factor=200
Building LambdaHack-0.5.1.0...
Preprocessing library LambdaHack-0.5.1.0...
Preprocessing executable 'LambdaHack' for LambdaHack-0.5.1.0...
[15 of 15] Compiling Main             ( GameDefinition/Main.hs, dist/build/LambdaHack/LambdaHack-tmp/Main.o )
Linking dist/build/LambdaHack/LambdaHack ...

The first step failed, so I skipped it.

bash$ git checkout master
error: pathspec 'master' did not match any file(s) known to git.
bash$ git branch
* simplifying-threaded-mode

Maybe we should give up on this.

comment:10 Changed 3 years ago by MikolajKonarski

Oh, I'm sorry, I asked you to make a clone with only one branch, so no wonder it has no others. Please start with

git clone https://github.com/LambdaHack/LambdaHack.git

comment:11 Changed 3 years ago by MikolajKonarski

Resolution: invalid
Status: newclosed

Hmm, but then, the commit exists also on that branch. So apparently you can't reproduce that. I will try this myself again when I install 8.0.2 or 8.0.3 and open a new ticket, if the problem persists for me. Closing.

comment:12 Changed 3 years ago by MikolajKonarski

BTW, should I open a new bug report with the panic I spotted in the travis log? (https://api.travis-ci.org/jobs/179766413/log.txt?deansi=true)

ghc: panic! (the 'impossible' happened)
  (GHC version 8.1.20161125 for x86_64-unknown-linux):
	Can't serialise IfaceTcTyVar
  u_aDzT[sk:1]
  Call stack:
      CallStack (from HasCallStack):
        prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable
        callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable
        pprPanic, called at compiler/iface/IfaceType.hs:1331:10 in ghc:IfaceType

comment:13 Changed 3 years ago by simonpj

Can't serialise IfaceTcTyVar: This will be very recent (ie HEAD only).

I fixed one of these yesterday; can you try again?

comment:14 Changed 3 years ago by MikolajKonarski

Oh, great, thanks for the fix. I just tried and it failed, but the HEAD on travis is ghc-head_8.1.20161125+git.0.f8c966c, so your fix is not yet included. If the problem persists when the HEAD is updated on travis, I will open a new ticket. BTW, I've tried on travis and couldn't reproduce Iface Id out of scope on any GHC version, with any optimization flags, so I'd probably need to recompile in a sandbox on my machine and attach sandbox config for reproduction, which is probably too much trouble for anybody willing to investigate (assuming it's enough to repro). Let's hope somebody finds a less fragile example or that it's caused by some bitrot on my machine.

Note: See TracTickets for help on using tickets.