Opened 6 years ago

Closed 4 years ago

#9070 closed bug (worksforme)

"Simplifier ticks exhausted"

Reported by: dermesser Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.6.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: x86_64 (amd64)
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


I know nothing more than what GHC said (I'm on debian, installed from the repositories).

(GHC version 7.6.3 for x86_64-unknown-linux):
	Simplifier ticks exhausted
    When trying UnfoldingDone base:GHC.Base.$fMonadIO_$c>>={v rJ2} [gid]
    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: 31764

The code triggering the error is the code commented out in lines 52-54:

 42     redis_family_raw <- getEnv redisFamilyVar
 43     redis_addr <- getEnv redisAddressVar
 44     redis_port <- getEnv redisPortVar
 46     (family,redis_family) <- case (parseFamily family_raw,parseFamily redis_family_raw) of
 47                     (Just fam, Just rfam) -> return (fam,rfam)
 48                     x -> fail $ "Unknown address family: " ++ show x
 50     sockaddr <- getSockAddr family broker_address broker_port_raw
 52     --redis_conn <- case redis_family of
 53     --                        WAFamilyInet -> R.connect $ defaultConnectInfo { connectHost = redis_addr, connectPort = Service redis_port }
 54     --                        WAFamilyUnix -> R.connect $ defaultConnectInfo { connectPort = UnixSocket redis_addr }

However, this bug occurs only when compiling with cabal.

Change History (5)

comment:1 Changed 6 years ago by DinoMorelli

I am seeing this now with a project starting with 7.8.2. I haven't seen any bugs here for this 'Simplifier ticks exhausted' problem with 7.8.2, should I start a new ticket?

This is on Arch Linux, 64-bit, ghc installed from the standard repositories (from Extra via pacman)

comment:2 Changed 6 years ago by carter

could you provide a link to the full codebase? also could you try building with -fno-full-laziness? (theres a few projects where ghc blows up in 7.8 that are Resolved by building with that flag)

is this with O1 or O2?

comment:3 Changed 6 years ago by simonpj

Exhausting the ticks isn't a real bug... it's just an indication that your program is doing an unusually large amount of simplification/optimisation work, given its size. That's intriguing (it'd be interesting to know why), but you should feel free to bump up the -fsimpl-tick-factor to make the warning go away.


comment:4 Changed 6 years ago by DinoMorelli


The project is epub-metadata. Available on Hackage, but I have already released a newer version with adjusted -fsimpl-tick-factor, so get the prior version:

$ cabal unpack epub-metadata-4.0

The error says:

When trying UnfoldingDone{v 04}

Still fails with just -fno-full-laziness, but the message changes to:

When trying UnfoldingDone hxt-$fCategory*IOSLA_$c.{v rzUB}

Also, I'm not specifying any -O switches at all, I'm not sure what the default optimization level is for GHC.


I was wondering about that, if this is normal-ish and just requires params.

Do you need me to provide more details here, perhaps with -ddump-simpl-stats ?

comment:5 Changed 4 years ago by thomie

Resolution: worksforme
Status: newclosed

I compiled epub-metadata-4.0 with ghc-7.8.4, and it required a -fsimpl-tick-factor of 110 (the default is 100). I also compiled it with ghc-7.10.2, and then it only required a -fsimpl-tick-factor of 10. Case closed.

Note: See TracTickets for help on using tickets.