- ghc-tickets - Haskell.org

[GHC] #10291: compiling huge HashSet hogs memory
by GHC 13 Apr '15

13 Apr '15

#10291: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Compiling a huge (~2.5k elements) set with GHC-7.10.1 or GHC-head and unordered-containers-0.2.5.1 or unordered-containers-head takes way too much memory. Here is a [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntitySet.hs file] which I am trying to compile. I've also set up a [https://travis- ci.org/zudov/html5-entity/builds/58063328 travis build] which demonstrates the behaviour with different versions of GHC and unordered-containers. Further I would be referring to [https://travis- ci.org/zudov/html5-entity/jobs/58063332 this build-job] which uses GHC-7.10.1 and unordered-containers-0.2.5.1. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L397 Compilation] with default optimization options takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L408 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L367 Compilation] with `-O0` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L378 400MB]. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L457 Compilation] with `-O2` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L468 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L487 Compilation] with `-O2 -fignore-interface-pragmas` takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L498 500MB] of memory, which solves the problem. When the build uses GHC-7.8.4, neither of this hogging [https://travis- ci.org/zudov/html5-entity/jobs/58063330 occurs]. Another interesting observation is that [https://travis- ci.org/zudov/html5-entity/jobs/58063330#L339 compiling] [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntityMap.hs HashMap] of the same size, doesn't cause memory hogging even with `-O2`. This attracted my attention as `HashSet` is implemented in terms of `HashMap`. I reported the issue to `unordered-containers` as well: [https://github.com/tibbe/unordered-containers/issues/100 link]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10291> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10290: compiling huge HashSet hogs memory
by GHC 13 Apr '15

13 Apr '15

#10290: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Compiling a huge (~2.5k elements) set with GHC-7.10.1 or GHC-head and unordered-containers-0.2.5.1 or unordered-containers-head takes way too much memory. Here is a [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntitySet.hs file] which I am trying to compile. I've also set up a [https://travis- ci.org/zudov/html5-entity/builds/58063328 travis build] which demonstrates the behaviour with different versions of GHC and unordered-containers. Further I would be referring to [https://travis- ci.org/zudov/html5-entity/jobs/58063332 this build-job] which uses GHC-7.10.1 and unordered-containers-0.2.5.1. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L397 Compilation] with default optimization options takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L408 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L367 Compilation] with `-O0` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L378 400MB]. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L457 Compilation] with `-O2` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L468 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L487 Compilation] with `-O2 -fignore-interface-pragmas` takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L498 500MB] of memory, which solves the problem. When the build uses GHC-7.8.4, neither of this hogging [https://travis- ci.org/zudov/html5-entity/jobs/58063330 occurs]. Another interesting observation is that [https://travis- ci.org/zudov/html5-entity/jobs/58063330#L339 compiling] [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntityMap.hs HashMap] of the same size, doesn't cause memory hogging even with `-O2`. This attracted my attention as `HashSet` is implemented in terms of `HashMap`. I reported the issue to `unordered-containers` as well: [https://github.com/tibbe/unordered-containers/issues/100 link]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10290> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows
by GHC 13 Apr '15

13 Apr '15

#2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | hsetbuffering buffering buffer Type of failure: None/Unknown | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Jedai): * cc: Jedai (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2189#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 12 Apr '15

12 Apr '15

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+----------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by hvr): Replying to [comment:39 rwbarton]: > hvr: So, what is the status of the in-tree GMP tarball now that 7.10.1 uses integer-gmp 1.*? Specifically where does the GMP library come from on OS X? Do we ship it as part of the binary distribution? Well, afaik, the official GHC bindist for OSX is configured to use the in- tree GMP, which for 7.10 is still at GMP 5.0.4 (and we can't upgrade the in-tree GMP till we make the switch to an externally fetched GMP tarball, but sadly Phab:D339 wasn't ready in time for 7.10 and still isn't...) You can btw easily find out which GMP version (and whether it was the intree or the system libgmp) `integer-gmp` was configured against by looking at the installed `<HsIntegerGmp.h>` header. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10282: Segfault when calling show on an Integer of a certain size
by GHC 11 Apr '15

11 Apr '15

#10282: Segfault when calling show on an Integer of a certain size -------------------------------------------+------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- You're not going to believe this. {{{ $ ghc -e 'let k = show (10^184000) in k == k' True $ ghc -e 'let k = show (10^187000) in k == k' True $ ghc -e 'let k = show (10^186000) in k == k' Bus error }}} That's right: there is a problem which affects Integer values which are 186000 digits long, but which does not affect values which are 187000 digits long. So {{{10^184000}}} works fine, {{{10^187000}}} works fine, but {{{10^186000}}} doesn't. What about {{{10^185000}}}? Well, it depends on your version of GHC. And on chance. GHC 7.10.0.20150123 is always happy with {{{10^185000}}}, but GHC 7.8.3 crashes about two-thirds of the time: {{{ $ ghc -e 'let k = show (10^185000) in k == k' True Segmentation fault }}} And it's a different kind of crash, too! A segmentation fault instead of a "bus error". I have tried all the lengths in {{{[1000,2000,..,100000]}}}, and some lengths are fine, some lengths have a bus error, and some lengths segfault. The most helpful lengths I've encountered give an error message about malloc: {{{ $ ghc -e 'let k = show (10^264000) in k == k' True ghc(72417,0x107081000) malloc: *** error for object 0x107300000: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap }}} Sometimes it gives a slightly different error message: {{{ $ ghc -e 'let k = show (10^264000) in k == k' ghc(72453,0x107381000) malloc: *** error for object 0x107200128: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Abort trap }}} Anyway, a lot more people posted their results in the following reddit thread, without realizing that the problem had to do with the length: http://www.reddit.com/r/haskell/comments/31yajd/can_you_explain_this/ So far, only folks on OS X have managed to reproduce the problem. The problem occurs with {{{ghci}}}, {{{runhaskell}}} and {{{ghc -e}}}, but not with compiled binaries. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10282> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 10 Apr '15

10 Apr '15

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+----------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): hvr: So, what is the status of the in-tree GMP tarball now that 7.10.1 uses integer-gmp 1.*? Specifically where does the GMP library come from on OS X? Do we ship it as part of the binary distribution? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10264: AArch64 : Installing 7.10.1 fails
by GHC 09 Apr '15

09 Apr '15

#10264: AArch64 : Installing 7.10.1 fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Built 7.10.1 from the release tarball, using ghc-7.6.3 from Debian. Build of the compiler goes fine, but when I install it I get: {{{ "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install \ "/home/erikd/GHC/7.10.1/lib/ghc-7.10.1/bin/ghc" \ "/home/erikd/GHC/7.10.1/lib/ghc-7.10.1/bin/ghc-pkg" \ "/home/erikd/GHC/7.10.1/lib/ghc-7.10.1" '' '/home/erikd/GHC/7.10.1' \ '/home/erikd/GHC/7.10.1/lib/ghc-7.10.1' \ '/home/erikd/GHC/7.10.1/share/doc/ghc/html/libraries' NO Warning: cannot determine version of /home/erikd/GHC/7.10.1/lib/ghc-7.10.1/bin/ghc-pkg : "" ghc-cabal: libraries/Cabal/Cabal/Distribution/Simple/GHC.hs:1050:5-47: Irrefutable pattern failed for pattern Data.Maybe.Just ver }}} The code in question is: {{{#!hs hcPkgInfo :: ProgramConfiguration -> HcPkg.HcPkgInfo hcPkgInfo conf = HcPkg.HcPkgInfo { HcPkg.hcPkgProgram = ghcPkgProg , HcPkg.noPkgDbStack = v < [6,9] , HcPkg.noVerboseFlag = v < [6,11] , HcPkg.flagPackageConf = v < [7,5] , HcPkg.useSingleFileDb = v < [7,9] } where v = versionBranch ver Just ghcPkgProg = lookupProgram ghcPkgProgram conf Just ver = programVersion ghcPkgProg }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10264> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10265: HEAD fails with -DDEBUG
by GHC 09 Apr '15

09 Apr '15

#10265: HEAD fails with -DDEBUG -------------------------------------+------------------------------------- Reporter: dalaing | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- With the following errors: compiler/main/Packages.hs:1269:11: Not in scope: data constructor ‘ASSERT’ compiler/main/Packages.hs:1271:11: Not in scope: data constructor ‘ASSERT’ compiler/main/Packages.hs:1286:11: Not in scope: data constructor ‘ASSERT’ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10265> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9965: getChanContents BlockedIndefinitelyOnMVar on 7.10 RC1
by GHC 09 Apr '15

09 Apr '15

#9965: getChanContents BlockedIndefinitelyOnMVar on 7.10 RC1 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1-rc1 libraries/base | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- All of the stanzas work on 7.8.3, but the middle one works incorrectly on 7.10: {{{#!hs module Main where import Control.Concurrent.Chan import Control.Monad main = do io <- newChan let inp = [0] :: [Int] mapM_ (writeChan io) inp {- -- WORKS: outp <- getChanContents io if 0 == head outp then putStrLn "OK" else error $ "Smoke test failed" -} -- BROKEN ON 7.10 (BlockedIndefinitelyOnMVar): outp <- getChanContents io if and (zipWith (==) inp outp) then putStrLn "OK" else error $ "Smoke test failed" {- -- WORKS: forM_ inp $ \xIn-> do xOut <- readChan io unless (xIn == xOut) $ error $ "Smoke test failed" -} }}} I first noticed the behavior in a Chan-like library I wrote, whose internals are completely different from Chan, but where the getChanContents is a copy-paste from Chan. So I assume it has something to do with `unsafeInterleaveIO`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9965> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10114: Kind mismatches with AnyK in rank-2 types
by GHC 08 Apr '15

08 Apr '15

#10114: Kind mismatches with AnyK in rank-2 types -------------------------------------+------------------------------------- Reporter: cam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following module: {{{#!hs {-# LANGUAGE Rank2Types #-} module KindBug where type T = forall f a. f a foo :: T foo = undefined bar :: forall f a. f a bar = foo }}} ...produces the following error: {{{ [1 of 1] Compiling KindBug ( KindBug.hs, KindBug.o ) KindBug.hs:10:7: Kind incompatibility when matching types: f0 :: AnyK -> * f :: * -> * Expected type: f a Actual type: f0 a0 Relevant bindings include bar :: f a (bound at KindBug.hs:10:1) In the expression: foo In an equation for ‘bar’: bar = foo }}} Note that no extensions are enabled other than rank-2 types. Enabling and using kind annotations fixes the error, as does replacing the type synonym with its definition in the type signature of foo. Similar errors can also be generated with PolyKinds enabled and less plausible code, e.g. {{{ (return undefined :: forall f a. f a) :: f a }}}. The non-PolyKinds example is simplified from some actual code, where the type synonym was similar to the ones used in lens, and is the simplest example I could find (with help from Shachaf on IRC) that resembled real code. I searched for existing tickets and the closest I could find are #7916 and #5935, both of which are already fixed. Also, according to glguy (Eric Mertens) just now in #haskell-lens, the same error occurs in the 7.10 branch and in 7.11.20150120. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10