April 2015 - ghc-tickets

[GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux
by GHC 14 Apr '15

14 Apr '15

#8276: Building Haddock documentation panics with perf build on x86_64 Linux ----------------------------------+--------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- After setting `BuildFlavor = perf` in `build.mk` compilation ends with a panic: {{{ "/home/luite/buildtest/ghc-clean-buildtest/ghc/inplace/bin/haddock" --odir="libraries/ghc-prim/dist-install/doc/html/ghc-prim" --no-tmp-comp- dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim /ghc-prim.haddock --html --hoogle --title="ghc-prim-0.3.1.0: GHC primitives" --prologue="libraries/ghc-prim/dist-install/haddock- prologue.txt" --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-H32m --optghc=-O --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist- install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc- prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc =-optP-include --optghc=-optPlibraries/ghc-prim/dist- install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build --source- module=src/%{MODULE/./-}.html --source- entity=src/%{MODULE/./-}.html#%{NAME} libraries/ghc- prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/CString.hs libraries/ghc- prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim /dist-install/build/GHC/PrimopWrappers.hs libraries/ghc- prim/./GHC/PrimWrappers.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries /ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine- readable Haddock coverage: 100% ( 1 / 1) in 'GHC.IntWord64' 78% ( 7 / 9) in 'GHC.Types' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /351) in 'GHC.PrimopWrappers' 2% ( 1 / 43) in 'GHC.PrimWrappers' 17% ( 1 / 6) in 'GHC.CString' 31% (170 /540) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' haddock: internal error: haddock: panic! (the 'impossible' happened) (GHC version 7.7.20130912 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.newSession or GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc- prim.haddock] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 }}} I've seen this problem before, but I thought that it was related to my patch. Now I got it on master branch and Luite reported the same problem on #ghc (log above is actually his). A workaround for this is disabling building of dicumentation in "perf" section of `build.mk`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 50

Re: [GHC] #7782: flag to run the demand analysis a second time
by GHC 14 Apr '15

14 Apr '15

#7782: flag to run the demand analysis a second time -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4941, #5302, | Blocking: #6087, #4962 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"d261d4cbcc867405f71d7c9580628f52978e2267/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d261d4cbcc867405f71d7c9580628f52978e2267" Zap usage info in CSE (Trac #10218) Trac #10218 reports a subtle bug that turned out to be: - CSE invalidated the usage information computed by earlier demand analysis, by increasing sharing - that made a single-entry thunk into a multi-entry thunk - and with -feager-blackholing, that led to <<loop>> The patch fixes it by making the CSE pass zap usage information for let-bound identifiers. It can be restored by -flate-dmd-anal. (But making -flate-dmd-anal the default needs some careful work; see Trac #7782.) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7782#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10300: GHC rejects
by GHC 14 Apr '15

14 Apr '15

#10300: GHC rejects -------------------------------------+------------------------------------- Reporter: mhwombat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: 10020 Differential Revisions: | -------------------------------------+------------------------------------- In GHC 7.8.4, the following code is legal: {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts #-} class FiniteGrid g where type Size s size :: g -> Size g maxPossibleDistance :: g -> Int }}} But with GHC 7.10.1, it no longer compiles. The error message is: {{{ The associated type ‘Size’ mentions none of the type or kind variables of the class ‘FiniteGrid g’ In the class declaration for ‘FiniteGrid’ }}} I didn't see any mention of this in the migration guide, but perhaps there's another pragma I need to enable. I thought this might be related to https://ghc.haskell.org/trac/ghc/ticket/10020, but that bug is apparently fixed in GHC 7.10.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10300> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7782: flag to run the demand analysis a second time
by GHC 14 Apr '15

14 Apr '15

#7782: flag to run the demand analysis a second time -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4941, #5302, | Blocking: #6087, #4962 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * owner: nfrisby => * priority: normal => high * status: closed => new * resolution: fixed => * milestone: 7.8.1 => 7.12.1 Comment: I'm re-opening this because we have not yet enabled `-flate-dmd-anal` by default, and I think we should. But there are caveats on [wike:LateDmd the LateDmd wiki page] that need exploring first. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7782#comment:13> 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 rwbarton): OK, well, for now there's no GMP release with the bug fixed anyways... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

12 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 12 Apr '15

12 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 12 Apr '15

12 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 10 Apr '15

10 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