Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#7898 closed bug (fixed)

SpecConstr explodes when compiling module BSP of frag-1.1.2

Reported by: tinctorius Owned by:
Priority: normal Milestone: 7.8.4
Component: Compiler Version: 7.6.3
Keywords: Cc: slyfox@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


GHC will get stuck when trying to compile Frag. Steps to reproduce:

  1. Get Frag 1.1.2 from the Darcs repository (darcs get, or from snowmantw's GitHub fork (git clone
  2. Fix the code so it'll actually compile:
    diff --git a/src/Textures.hs b/src/Textures.hs
    index 7383fd8..b5516a5 100644
    --- a/src/Textures.hs
    +++ b/src/Textures.hs
    @@ -10,6 +10,7 @@ import Graphics.UI.GLUT
     import TGA (readTga)
     import Data.Word (Word8)
     import Foreign.Marshal.Alloc (free)
    +import Control.Exception (catch, SomeException)
     -- read a list of images and returns a list of textures
    @@ -32,7 +33,8 @@ getAndCreateTexture fileName = do
     -- read the image data
     readImageC :: String -> IO (Maybe (Size, PixelData Word8))
    -readImageC path = catch (readTga path) (\_ -> do print ("missing texture: "++path)
    +readImageC path = catch (readTga path) (\e -> do print (e :: SomeException)
    +                                                 print ("missing texture: "++path)
                                                      return Nothing)
  3. cabal configure
  4. cabal build

GHC will get stuck on the module BSP and consume memory until it crashes. According to this ticket on the GitHub fork mentioned earlier, this problem only occurs with -O2.

When I split the reading part of the module (readBSP and all functions it depends on), it crashed on that part. Will investigate further.

Change History (18)

comment:1 Changed 6 years ago by tinctorius

-O2 seems to be the culprit. When removing the flag from the Cabal file, it'll compile. Eventually.

diff --git a/frag.cabal b/frag.cabal
index 8893fb0..3c32cdf 100644
--- a/frag.cabal
+++ b/frag.cabal
@@ -85,7 +85,6 @@ Executable frag
    Main-is:             Main.hs
    Build-Depends:       base==4.*, GLUT, OpenGL>=2.0, array, random
    Hs-source-dirs:      src
-   Ghc-options:         -O2 -funbox-strict-fields -fvia-C -optc-O2
    Extensions:          BangPatterns,

comment:2 Changed 6 years ago by exbb2

I remember that this bug has been already in ghc-7.2.1 or in ghc-7.0.1 — i tried to compile frag about a year ago; didn't knew that darcs repo contains version that builds for newer ghc, had to patch it until i got to BSP.

comment:3 Changed 6 years ago by amosrobinson

This looks somewhat similar to #5550, but is not the same. SpecConstr is indeed blowing up massively:

Result size of Simplifier = 291502
*** SpecConstr:
Result size of SpecConstr = 3164185

but it does terminate eventually (for me on 7.4.2, at least).

I have a tentative patch to try removing some SpecConstr blowups (by seeding specialisation for top-level bindings similar to what is already done for letrecs) but I won't get a chance to try that on this example until Monday.

comment:4 Changed 6 years ago by amosrobinson

For now, though, you could try compiling with -O2 -fno-spec-constr.

comment:5 Changed 6 years ago by tinctorius

Summary: Compiler diverges when compiling module BSP of frag-1.1.2SpecConstr explodes when compiling module BSP of frag-1.1.2

Splitting off cIntSize, getLumpData, kIndices, readHeader, readIndices, and readLump into a separate module greatly reduces the problem. It still takes unreasonably long to compile, though.

comment:6 Changed 6 years ago by amosrobinson

Annoyingly, GLUT won't install on ghc-head at the moment, and the BSP module seems to actually rely on GLUT for something. I'll see if I can split out the reading part without GLUT

comment:7 Changed 6 years ago by amosrobinson

This is strange. I managed to get OpenGL to install on head (had to comment out the Typeable instances). Head still has the same blowup problem.

Then I split BSP into two modules: reading and rendering. Then, bizarrely, neither of those modules blew up. I don't understand how splitting it into two modules could stop specialisation from happening, but it seems to. Same behaviour on head & 7.4.2.

I'm going to try selectively removing/undefining parts of the original BSP until I get something small enough that still blows up but the core is readable.

comment:8 Changed 6 years ago by amosrobinson

Haha! if you remove the export list is compiles immediately!

comment:9 Changed 6 years ago by simonpj

difficulty: Unknown

Amos, it sounds as if you are onto something! Great. If you can boil it down to something I can reproduce without massive heroics, and if you are stuck, I'll willingly take a look.


comment:10 Changed 6 years ago by simonpj

See also #7928, which sounds very similar.

comment:11 Changed 6 years ago by amosrobinson

I'm sorry, I've kind of dropped the ball on this. So, SpecConstr is definitely blowing up (235,000 to 3,000,000 or something). But! Before that, the simplifier is blowing up from 5,000 to 235,000. I know a certain amount of increase is expected from inlining in the simplifier, but this seems excessive. So I suspect it's actually inlining too much?

I don't have a good example, but #7928 looks like it might be easier to get into a standalone test case.

comment:12 Changed 6 years ago by simonpj

OK, thanks Amos. I'm utterly snowed under, so you are holding the token on this SpecConstr blowup (thank you). Everyone else: yell if this is mission-critical.


comment:13 Changed 6 years ago by slyfox

Cc: slyfox@… added

comment:14 Changed 5 years ago by carter

a related instance of spec constr blowup was found in idris when built with O2 where the javascript codegen module

likewise the last line of the log is

*** SpecConstr:

not sure if this should be its own ticket or not, for now adding it here

comment:15 Changed 5 years ago by simonpj

I believe this is finally fixed; see #8852. Can you try now, with HEAD?


comment:16 Changed 5 years ago by tinctorius

No problems with GHC HEAD. Consider it fixed :D

comment:17 Changed 5 years ago by rwbarton

Resolution: fixed
Status: newclosed

comment:18 Changed 5 years ago by tibbe

Milestone: 7.8.4
Note: See TracTickets for help on using tickets.