Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#9971 closed bug (fixed)

GHC 7.10 dies with "out of memory"

Reported by: albertov Owned by:
Priority: highest Milestone: 7.10.1
Component: Compiler Version: 7.10.1-rc1
Keywords: Cc:
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Compile-time crash Test Case: typecheck/should_compile/T9971
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

I'm trying to build my library with cabal 1.22 and ghc-7.10.0.20141222 but it ultimately crashes with ghc: out of memory (requested 2097152 bytes). The VM I've used to build it has 8gb of RAM. The same library compiles fine with ghc 7.8.3 so I guess it is a GHC bug.

Unfortunately I'm not able to reduce it to a simple case or relate it to a previous bug. The build log can be seen at travis-ci and the source code is freely available so it should be easy to reproduce

Attachments (3)

build.log (7.8 KB) - added by albertov 4 years ago.
build.2.log (6.3 KB) - added by albertov 4 years ago.
ghc9971.tar.gz (875 bytes) - added by albertov 4 years ago.
Simple project that reproduces the bug

Download all attachments as: .zip

Change History (19)

comment:1 Changed 4 years ago by albertov

I've narrowed the problem to a specific source file and a specific commit. Since these changes where made to the Types.hs module GHC 7.10 starts consuming all available RAM until the OS kills it when trying to compile it.

comment:2 Changed 4 years ago by nomeata

You added UndecidableInstances there. This means: „My typeclass instances may not be terminating, so when GHC runs into an infinite loop here, it’s my fault.“ I did not yet check whether this is the problem, but in a way, you voided the warranty here. Can you reproduce the problem without UndecidableInstances?

comment:3 in reply to:  2 Changed 4 years ago by albertov

Replying to nomeata:

You added UndecidableInstances there. This means: „My typeclass instances may not be terminating, so when GHC runs into an infinite loop here, it’s my fault.“ I did not yet check whether this is the problem, but in a way, you voided the warranty here. Can you reproduce the problem without UndecidableInstances?

The problem occurs without UndecidableInstances too since Types.hs is not using it at all. I've used UndecidableInstances on another module (Arbitrary.hs) but it doesn't get a chance to get compiled since it depends on Types.hs which is the problematic module.

comment:4 Changed 4 years ago by nomeata

Sorry, could have seen that. It was worth a shot, though.

comment:5 Changed 4 years ago by carter

@albertov: could you attach a transcript of building that file with ghc -v3? (that will show us where the build is getting stuck hopefully) Also: what optimization level /other flags are you giving ghc

comment:6 Changed 4 years ago by carter

hrmm, it also looks like your cabal file hard sets the -O2 flag. could you try building with -O1 or -O0 instead?

Changed 4 years ago by albertov

Attachment: build.log added

comment:7 Changed 4 years ago by albertov

I've created a new branch in my library to track this down from the first revision that causes the problem (2b00e8f5052cc392). I've removed the -O2 flag from the test section of the .cabal file (the library section didn't have it) and configured with: cabal configure --disable-optimization --ghc-options="-v3" --enable-tests -w /usr/local/bin/ghc-7.10.0.20141222. The output of the configure step is:

Resolving dependencies...
Configuring sigym4-geometry-0.1.0.2...
Glasgow Haskell Compiler, Version 7.10.0.20141222, stage 2 booted by GHC version 7.8.3
Using binary package database: /usr/local/lib/ghc-7.10.0.20141222/package.conf.d/package.cache
Using binary package database: /home/alberto/.ghc/x86_64-linux-7.10.0.20141222/package.conf.d/package.cache
wired-in package ghc-prim mapped to ghc-prim-0.3.1.0-ef8d733e55253d54bc20910b190b4671
wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-1c365c75fd598ef8737ed7c605ee03d2
wired-in package base mapped to base-4.8.0.0-e29e6aeb808f5a1814cb5be39ea4f618
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.10.0.0-4568f09ac38ddc61b7786e2a3f416f4b
wired-in package ghc mapped to ghc-7.10.0.20141222-6718a8ae216097cfa2a99e476432dc11
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags:
Created temporary directory: /tmp/ghc20749_0
*** C Compiler:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -x c /tmp/20700.c -o /tmp/ghc20749_0/ghc20749_1.s -Wimplicit -S '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc-7.10.0.20141222/include/ghcversion.h -I/usr/local/lib/ghc-7.10.0.20141222/base_469rOtLAqwTGFEOGWxSUiQ/include -I/usr/local/lib/ghc-7.10.0.20141222/integ_21cuTlnn00eFNd4GMrxOMi/include -I/usr/local/lib/ghc-7.10.0.20141222/include
*** Assembler:
/usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -x assembler -c /tmp/ghc20749_0/ghc20749_1.s -o /tmp/20700.o
*** Deleting temp files:
Deleting: /tmp/ghc20749_0/ghc20749_1.s
*** Deleting temp dirs:
Deleting: /tmp/ghc20749_0

The executed cabal build > build.log 2>&1and waited for the OS to kill ghc. I've attached the resulting build.log file.

comment:8 Changed 4 years ago by albertov

I'm going to try to narrow it down further by removing code from Types.hs until it compiles fine and then adding back the problematic part. Hopefully it this strategy works out.. I'll report back anyway.

comment:9 Changed 4 years ago by albertov

Interesting... I've managed to sidestep the bug by changing unboxed vectors to boxed vectors (from the vector package). These are the changes I've made. So it seems related somehow to the use of unboxed vectors. Hopefully this helps.

comment:10 Changed 4 years ago by albertov

Damn, ignore my previous comments regarding unboxed vectors. I've unconfigured my build by accident by deleting the dist directory and it was 7.8.3 building it :( Sorry for the noise. I'll rinse and repeat and hopefully provide some useful information.

comment:11 Changed 4 years ago by albertov

Ok, now for real. It seems the culprit is the code generated by derivingUnbox "Point". The changes that sidestep the bug are these.

I've reconfigured with cabal configure --disable-optimization --ghc-options="-ddump-splices" --enable-tests -w /usr/local/bin/ghc-7.10.0.20141222, added back the derivingUnbox part (which now I'm positive that it's the real culprit) and I'm attaching the build output with the generated TH code.

Changed 4 years ago by albertov

Attachment: build.2.log added

Changed 4 years ago by albertov

Attachment: ghc9971.tar.gz added

Simple project that reproduces the bug

comment:12 Changed 4 years ago by albertov

I've just attached a simple project that reproduces the bug. The module is essentially this:

{-# LANGUAGE TemplateHaskell
           , MultiParamTypeClasses
           , TypeFamilies
           #-}
module Demo9971 where

import qualified Data.Vector.Unboxed as U
import Data.Vector.Unboxed.Deriving (derivingUnbox)

type Vertex v = v Double

newtype Point v = Point {_pVertex:: Vertex v}

class U.Unbox (Vertex v) => VectorSpace v where

derivingUnbox "Point"
    [t| VectorSpace v => Point v -> Vertex v |]
    [| \(Point v) -> v |]
    [| \v -> Point v|]

To reproduce just create a sandbox, install dependencies and build. GHC will begin to consume all memory until it is killed when building Demo9971.hs

comment:13 Changed 4 years ago by Simon Peyton Jones <simonpj@…>

In 854e7b8efdd7fe5fcba77e1e049e8a835f03b16a/ghc:

Fix a terrible bug in the canonicaliser which led to an infinite loop

This fixes Trac #9971

Merge into the 7.10 branch

comment:14 Changed 4 years ago by simonpj

Milestone: 7.10.1
Priority: normalhighest
Status: newmerge
Test Case: typecheck/should_compile/T9971

A very fine bug thank you! Fixed.

Merge to 7.10 branch

Simon

comment:15 Changed 4 years ago by hvr

Resolution: fixed
Status: mergeclosed

comment:16 Changed 4 years ago by albertov

My library is building properly now with c9ab42f84531f71056cfdf686cf548481b0af389 (albeit with a handful of new warnings I'll proceed to fix) Thanks!

Note: See TracTickets for help on using tickets.