March 2018 - ghc-tickets

[GHC] #14431: Peculiar RTS crash on OS X
by GHC 08 Mar '18

08 Mar '18

#14431: Peculiar RTS crash on OS X ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- This [[https://phabricator.haskell.org/harbormaster/build/36804/|Harbormaster build]] failed with an odd RTS crash from the stage0 compiler (which is 8.2.1), {{{ ghc: internal error: RELEASE_LOCK: I do not own this lock: rts/posix/itimer/Pthread.c 187 (GHC version 8.2.1 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It's not immediately clear to me from the implementation how this could happen, but I thought I should at least note the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14431> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14538: forkprocess01 fails occassionally on with multiple ACQUIRE_LOCK panic
by GHC 08 Mar '18

08 Mar '18

#14538: forkprocess01 fails occassionally on with multiple ACQUIRE_LOCK panic ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I noticed that `forkprocess01` failed to build on Darwin and commit eb86e867694bceedfb47a527d71429197ffe6dda with {{{ Stderr ( forkprocess01 ): forkprocess01: internal error: multiple ACQUIRE_LOCK: rts/Task.c 228 (GHC version 8.3.20171128 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug /bin/sh: line 1: 5124 Abort trap: 6 ./forkprocess01 +RTS -ls -RTS *** unexpected failure for forkprocess01(threaded1_ls) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14538> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

Re: [GHC] #2783: RTS -K/-M options not honored
by GHC 08 Mar '18

08 Mar '18

#2783: RTS -K/-M options not honored -----------------------------------+------------------------------ Reporter: j.waldmann | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+------------------------------ Old description: > I have this program > > main = print $ do x <- [ 0 .. 5 ] ; let { y = 5 - y } ; return y > > I compile with ghc-6.10.1 --make > > and I execute with +RTS -M10m -K10m > > but still the executable quickly eats up all my memory. > > (I know the program is silly but still it should crash > gracefully.) > > When I do the same thing with ghc-6.8.3, > I get "Heap exhausted", as it should be. New description: I have this program {{{#!hs main = print $ do x <- [ 0 .. 5 ] ; let { y = 5 - y } ; return y }}} I compile with `ghc-6.10.1 --make` and I execute with `+RTS -M10m -K10m` but still the executable quickly eats up all my memory. (I know the program is silly but still it should crash gracefully.) When I do the same thing with ghc-6.8.3, I get "Heap exhausted", as it should be. -- Comment (by bgamari): Sounds like a bug to me, but it's not the bug covered by this ticket. Let's open a new ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2783#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5129: "evaluate" optimized away
by GHC 08 Mar '18

08 Mar '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D615 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: simonmar => (none) * status: closed => new * resolution: fixed => Comment: Let's reopen this (or open a new ticket to track these). These competing bottoms are tricky! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2783: RTS -K/-M options not honored
by GHC 08 Mar '18

08 Mar '18

#2783: RTS -K/-M options not honored -----------------------------------+------------------------------ Reporter: j.waldmann | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+------------------------------ Changes (by alpmestan): * failure: => None/Unknown Comment: When running `./validate --slow` yesterday, I saw the test for this ticket failing with the `threaded1` way. Instead of detecting the loop and aborting with an informative message, we get an assertion failure in the `rts/ThreadPaused.c:threadPaused` function. The program: {{{#!hs main = print $ do x <- [ 0 .. 5 ] ; let { y = 5 - y } ; return y }}} The output: {{{ =====> T2783(threaded1) 1 of 1 [0, 0, 0] cd "./rts/T2783.run" && "/home/alp/ghc/inplace/test spaces/ghc-stage2" -o T2783 T2783.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug cd "./rts/T2783.run" && ./T2783 Wrong exit code for T2783(threaded1)(expected 1 , actual 134 ) Stderr ( T2783 ): T2783: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 (GHC version 8.5.20180306 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) *** unexpected failure for T2783(threaded1) }}} The code for the corresponding assertion: {{{#!c // We should never have made it here in the event of blackholes that // we already own; they should have been marked when we blackholed // them and consequently we should have stopped our stack walk // above. ASSERT(!((bh_info == &stg_BLACKHOLE_info) && (((StgInd*)bh)->indirectee == (StgClosure*)tso))); }}} This actually is unexpected _ang_ a bug, right? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2783#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC
by GHC 08 Mar '18

08 Mar '18

#4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: kaiha Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | driver/T4114a,b,c,d Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Phab:D2021 Wiki Page: | Phab:D2050 -------------------------------------+------------------------------------- Comment (by alpmestan): With master from yesterday, T4114c and T4114d are failing with the `ghci` way: {{{ =====> T4114c(ghci) 1 of 2 [0, 0, 0] cd "./driver/T4114c.run" && "/home/alp/ghc/inplace/test spaces/ghc- stage2" T4114c.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output -fobject-code --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -no- keep-o-files< T4114c.genscript Wrong exit code for T4114c(ghci) (expected 0 , actual 1 ) Stderr ( T4114c ): T4114c: error: intermediate 'T4114cSub.o' exists CallStack (from HasCallStack): error, called at ./T4114cSub.hs:9:8 in main:T4114cSub *** unexpected failure for T4114c(ghci) =====> T4114d(ghci) 2 of 2 [0, 1, 0] cd "./driver/T4114d.run" && "/home/alp/ghc/inplace/test spaces/ghc- stage2" T4114d.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output -fobject-code --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -hisuf .myhi -osuf .myo -no-keep-o-files< T4114d.genscript Wrong exit code for T4114d(ghci) (expected 0 , actual 1 ) Stderr ( T4114d ): T4114d: error: intermediate 'T4114dSub.myo' exists CallStack (from HasCallStack): error, called at ./T4114dSub.hs:9:8 in main:T4114dSub *** unexpected failure for T4114d(ghci) }}} So it looks like `--interactive` does not honor `-no-keep-o-files` anymore. Shall I push a patch that expects just this way to fail, or shall I look into this somewhat soon to fix it instead? Or both I guess? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4114#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5129: "evaluate" optimized away
by GHC 07 Mar '18

07 Mar '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D615 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): A recent `./validate --slow` run I did revealed that this test doesn't pass anymore. I found out that something changed between `8.0.2` and `8.2.1`: {{{#!sh $ nix-shell -p haskell.compiler.ghc821 --run 'ghc-8.2.1 -O -fforce-recomp ~/ghc/testsuite/tests/codeGen/should_run/T5129.hs && /home/alp/ghc/testsuite/tests/codeGen/should_run/T5129' [1 of 1] Compiling Main ( /home/alp/ghc/testsuite/tests/codeGen/should_run/T5129.hs, /home/alp/ghc/testsuite/tests/codeGen/should_run/T5129.o ) Linking /home/alp/ghc/testsuite/tests/codeGen/should_run/T5129 ... T5129: HUnitFailure "must throw when given a negative number" $ nix-shell -p haskell.compiler.ghc802 --run 'ghc-8.0.2 -O -fforce-recomp ~/ghc/testsuite/tests/codeGen/should_run/T5129.hs && /home/alp/ghc/testsuite/tests/codeGen/should_run/T5129' [1 of 1] Compiling Main ( /home/alp/ghc/testsuite/tests/codeGen/should_run/T5129.hs, /home/alp/ghc/testsuite/tests/codeGen/should_run/T5129.o ) Linking /home/alp/ghc/testsuite/tests/codeGen/should_run/T5129 ... $ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14898: Panic with repSplitAppTys
by GHC 07 Mar '18

07 Mar '18

#14898: Panic with repSplitAppTys -------------------------------------+------------------------------------- Reporter: ryanreich | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I get a GHC panic while compiling a rather large module that contains a fairly simple function: {{{#!hs import Control.Monad.Reader usingReader :: (Monad m) => r -> (a -> ReaderT r m b) (a -> m b) usingReader r f = flip runReaderT r . f }}} Unfortunately, that function alone in a module does not trigger the panic. The error message is: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): repSplitAppTys a_ahFs[sk:1] ReaderT r_ahFr[sk:1] m_ahFq[sk:1] b_ahFt[sk:1] [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14898> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm)
by GHC 07 Mar '18

07 Mar '18

#11330: Test `dynamic-paper` fails with core lint error (hpc) and "Simplifier ticks exhausted" (optasm) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghc-head --info | grep Project [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","8.1.20151231") ,("Project Git commit id","8afeaad919dc67643b4eff14efafb48b59039b2b") }}} {{{ $ make slowtest TEST=dynamic-paper VERBOSE=2 TEST_HC=ghc-head ... =====> dynamic-paper(normal) 1 of 1 [0, 0, 0] =====> dynamic-paper(hpc) 1 of 1 [0, 0, 0] ... Compile failed (status 256) errors were: *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) *** <no location info>: warning: In a case alternative: (TypeRepX k_s7Ec :: *, a_s7Ed :: k_a5px, tr2_s7Ee :: TypeRep a_s7Ed) @ k_a5px is out of scope *** Offending Program *** ... <no location info>: error: Compilation had errors *** unexpected failure for dynamic-paper(hpc) =====> dynamic-paper(optasm) 1 of 1 [0, 1, 0] Compile failed (status 256) errors were: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20151231 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone delta1 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: 203160 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for dynamic-paper(optasm) Unexpected results from: TEST="dynamic-paper" }}} This test was added in commit 52da6bdc17bb491d6d2f462b3680eb44b9be92e5: {{{ Author: Richard Eisenberg <eir(a)cis.upenn.edu> Date: Sat Dec 26 09:11:33 2015 -0500 Have mkCastTy look more closely for reflexivity. This may have performance implications. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12506: Compile time regression in GHC 8.
by GHC 07 Mar '18

07 Mar '18

#12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This bug is entirely reproducible but unfortunately takes some setup. I don't have a minimal example. The regression is happening in FLTKHS (https://github.com/deech/fltkhs) the Haskell bindings to the FLTK(http://fltk.org) toolkit, and in particular to this GUI (https://github.com/deech/fltkhs/blob/master/images /tree-complex-windows.png). In GHC 7.8, it taks 5-9 seconds to compile and link in 7.10.3, that goes up to 12-15 seconds and finally in GHC 8 it shoots up to 45 seconds. While these numbers come from my i7, 16GB RAM Linux laptop, the compile time regression is proportionally reproducible across machines and operating systems. Here are the steps to reproduce it * Install FLTK Please follow the instructions here (https://github.com/deech/fltkhs #linux-and-bsd) but only the first set which about for installing FLTK 1.3. * Clone the repo with the offending application: `git clone https://github.com/deech/fltkhs-fluid-demos` * Build the application and reproduce the problem: - `cabal install fltkhs` - At the root of the repo do `cabal build fltkhs-fluid-tree` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34