September 2014 - ghc-tickets

[GHC] #9640: Invalid object in processHeapClosureForDead(): 2130762223
by GHC 19 May '18

19 May '18

#9640: Invalid object in processHeapClosureForDead(): 2130762223 -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I just tried using {{{-hb}}} profiling for Yi and hit {{{ yi: internal error: Invalid object in processHeapClosureForDead(): 2130762223 (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} Unfortunately I don't have an easy way to replicate. In my case it's to check out HEAD version of Yi, build with profiling and run {{{ [nix-shell:~/programming/yi/yi]$ TERM=xterm yi_datadir=. dist/build/yi/yi -fpango --as=emacs -y /tmp /tmp/long +RTS -p -hb }}} where {{{/tmp/long}}} here is just a file with 1MB of the letter {{{A}}} repeated on a single line. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9640> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion
by GHC 16 May '18

16 May '18

#8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion -------------------------------------------+------------------------------- Reporter: merijn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: patch | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Runtime Blocked By: | crash Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Due to an unsafe coercion in GHC.Event.Poll.poll the implementation has a bug that on some platforms (.e.g. linux) results in subtly wrong semantics and on other platforms (e.g. OS X) downright crashes the runtime. The offending line is line 95 in GHC/Event/Poll.hsc: {{{ c_poll ptr (fromIntegral len) (fromIntegral (fromTimeout tout)) }}} `fromTimeout` returns a timeout in seconds as a value of type Int. `c_poll` takes a timeout in seconds as a value of type CInt. If the max value of Int is larger than that of CInt, this coercion results in an overflow, producing a negative value. The faulty semantics are in turn caused by passing this negative value as timeout to `c_poll`. This overflow happens on many 64bit platforms where GHC's Int is 64bit, but CInt is often 32bit. The result of passing a negative value to poll() depends on the platform, but is (on all platforms I checked) different from the desired semantics! On linux any negative timeouts are treated as infinite, this means that a poll() with a timeout that should be finite results in an infinitely blocking poll on linux! On OSX any negative timeout other than -1 (which is treated as infinity) is considered an invalid parameter, returning an error and crashing the runtime. A minimal example reproducing the error (on systems where `fromIntegral (maxBound :: Int) > (fromIntegral (maxBound :: CInt) :: Integer)`): {{{ import Control.Concurrent main = threadDelay maxBound }}} Using 64bit GHC on OSX this produces an immediate runtime crash. The attached patch solves the issue by comparing the Int timeout against the max value of CInt and, if necessary, looping multiple `c_poll` calls (with a timeout equal to `maxBound :: CInt`) if they return `0` (which indicates the timeout has expired with no events occurring). See also: https://github.com/merijn/packages- base/commit/6d8ea02a3f6a2cdb82a9ad786a8c4db780b92091 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #8995: When generalising, use levels rather than global tyvars
by GHC 05 May '18

05 May '18

#8995: When generalising, use levels rather than global tyvars ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A long time ago Didier Remy described how to use 'ranks' or 'levels' to make the test "is this type variable free in the environment" when generalising a type. Oleg gives a [http://okmij.org/ftp/ML/generalization.html great explanation here]. GHC still uses the old "find the free type variables in the environment" method. But in fact GHC ''does'' maintain levels, just as Didier explains. The level is called `Untouchables` and is used to make sure we don't infer non-principal types for things involving GADTs. The same level stuff is used to prevent skolem-escape. Details with `Note [Untouchable type variables]` and `Note [Skolem escape prevention]` in `TcType`. So it ought to be straightforward to use the same levels for generalisation. I had a go, and came across the following tricky points: * We need to bump the level (`pushUntouchables`) when starting to typecheck a let RHS. Currently we don't. That will be a bit less efficient, because we'll end up deferring unification constraints that currently get solved immediately. * However the current set up is actually wrong. In particular, we generate a constraint where the implications do not have monotonically increasing level numbers (invariant `(ImplicInv)` in `TcType`). Try this program with `-ddump-tc-trace`. {{{ {-# LANGUAGE GADTs #-} module Bar where data T where MkT :: a -> (a->Int) -> T f x z = case x of MkT _ _ -> let g y = (y, [z,Nothing]) in (g True, g 'c') }}} I don't know how to make this bug cause an actual problem, but it's very unsettling. Bumping the level before doing the RHS would solve this. * Once we have bumped the level, we then have to do some more type- variable promotion, especially of type variables free in the finally- chosen type of the binder. This came out rather awkwardly in the code. * Because we now get more deferred equality constraints, there's a real risk that we'll end up quantifying over them. If we get, say `(gbl ~ Maybe lcl)`, where `gbl` is a type var free in the envt, we '''do not''' want to quantify over it! (It would be sound, but would lead to horrible types.) A long time ago Didier Remy described how to use 'ranks' or 'levels' to make the test "is this type variable free in the environment" when generalising a type. Oleg gives a [http://okmij.org/ftp/ML/generalization.html great explanation here]. GHC still uses the old "find the free type variables in the environment" method. But in fact GHC ''does'' maintain levels, just as Didier explains. The level is called `Untouchables` and is used to make sure we don't infer non-principal types for things involving GADTs. The same level stuff is used to prevent skolem-escape. Details with `Note [Untouchable type variables]` and `Note [Skolem escape prevention]` in `TcType`. So it ought to be straightforward to use the same levels for generalisation. I had a go, and came across the following tricky points: * We need to bump the level (`pushUntouchables`) when starting to typecheck a let RHS. Currently we don't. That will be a bit less efficient, because we'll end up deferring unification constraints that currently get solved immediately. * However the current set up is actually wrong. In particular, we generate a constraint where the implications do not have monotonically increasing level numbers (invariant `(ImplicInv)` in `TcType`). Try this program with `-ddump-tc-trace`. {{{ {-# LANGUAGE ExistentialQuantification #-} module Bar where data T = forall a. MkT a f x z = case x of MkT y -> let g y = [y,Nothing] in g True }}} Look for the `reportUnsolved` trace and you'll nested implications, both with level 1. I don't know how to make this bug cause an actual problem, but it's very unsettling. Bumping the level before doing the RHS would solve this. * Once we have bumped the level, we then have to do some more type- variable promotion, especially of type variables free in the finally- chosen type of the binder. This came out rather awkwardly in the code. * Because we now get more deferred equality constraints, there's a real risk that we'll end up quantifying over them. If we get, say `(gbl ~ Maybe lcl)`, where `gbl` is a type var free in the envt, we '''do not''' want to quantify over it! (It would be sound, but would lead to horrible types.) Rather we want to promote `lcl`, and not quantify. Currently we don't get many deferred equality constraints, becuase they all get done "on the fly". But if we do get one, we do quantify over it, which yields a rather stupid type. Try this: {{{ {-# LANGUAGE ExistentialQuantification #-} module Bar where data T = forall a. MkT a f x z = case x of MkT _ -> let g y = [z,Nothing] in (g True, g 'c') }}} We get this `g :: forall t a2. Maybe a ~ Maybe a2 => t -> [Maybe a2]`, where `x::a` is in the envt. Not very clever! This only shows up with existentials and In general I think we want to find all the type variables reachable by equality constraints from the environment, and not quantify over them. * We also use the type environment `getGlobalTyVars` in ''kind'' generalisation, and kind inference currently does not use the untoucahble story. Adapting it to use levels might be tricky because we currently assume we solve all kind equality constraints on-the-fly, and don't gather any deferreed constraints. Maybe it's easy, but needs thought. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8995> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9113: Template Haskell should warn about non-exhaustive pattern matches
by GHC 03 May '18

03 May '18

#9113: Template Haskell should warn about non-exhaustive pattern matches -------------------------+------------------------------------------------- Reporter: tvh | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.8.2 Component: | Operating System: Unknown/Multiple Template Haskell | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- When using Typed Template Haskell, There are no warings for non-exhaustive patterns inside the quote. {{{ {-# LANGUAGE TemplateHaskell #-} module Foo where import Language.Haskell.TH.Lib foo :: Maybe Int -> TExpQ Bool foo x = [||case x of Nothing -> False||] }}} Instead the warnings appear where the code is spliced. {{{ {-# LANGUAGE TemplateHaskell #-} module Bar where import Foo x = $$(foo (Just 1)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9113> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies
by GHC 03 May '18

03 May '18

#8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies ------------------------------------+------------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The code is: {{{ data K = Foo | Bar data D1 :: K -> * where F1 :: D1 Foo B1 :: D1 Bar class C (a :: K -> *) where data D2 a :: K -> * foo :: a k -> D2 a k -> Bool instance C D1 where data D2 D1 k where F2 :: D2 D1 Foo B2 :: D2 D1 Bar foo F1 F2 = True foo B1 B2 = True }}} With -Wall it gives the warning: {{{ Test.hs:23:5: Warning: Pattern match(es) are non-exhaustive In an equation for `foo': Patterns not matched: F1 B2 B1 F2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8853: Alarming looking warning about non-exhaustive pattern
by GHC 03 May '18

03 May '18

#8853: Alarming looking warning about non-exhaustive pattern -------------------------+------------------------------------------------- Reporter: | Owner: MikolajKonarski | Status: new Type: bug | Milestone: Priority: | Version: 7.8.1-rc2 normal | Operating System: Linux Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: x86_64 (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- The attached code produces this alarming warning: ~/waste$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 ~/waste$ ghc -Wall --make AlarmingPattern.hs -fforce-recomp [1 of 1] Compiling Main ( AlarmingPattern.hs, AlarmingPattern.o ) AlarmingPattern.hs:6:7: Warning: Pattern match(es) are non-exhaustive In an equation for ‘takeFromInv’: Patterns not matched: (GHC.Types.I# _) (GHC.Types.I# (#x)) with #x `notElem` [0#] Linking AlarmingPattern ... ~/waste$ ./AlarmingPattern AlarmingPattern: AlarmingPattern.hs:(6,7)-(7,26): Non-exhaustive patterns in function takeFromInv -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8494: Warn if a pattern guard obviates all others
by GHC 03 May '18

03 May '18

#8494: Warn if a pattern guard obviates all others -------------------------+------------------------------------------------- Reporter: | Owner: JohnWiegley | Status: new Type: | Milestone: feature request | Version: 7.6.3 Priority: | Operating System: Unknown/Multiple normal | Type of failure: Incorrect warning at Component: | compile-time Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- The following code, when compiled with `-Wall`, gives no warnings: {{{ module Main where main :: IO () main = print $ foo (10 :: Int) where foo x | True = (20 :: Int) | x == 10 = (30 :: Int) }}} I would expect that since the pattern guard `| True` obviates the following guards, that it would warn about unreachable code. There was a bug in my code today which I tracked down to a code transposition that would have been easily spotted with such a warning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8406: Invalid object in isRetainer() or Segfault
by GHC 25 Apr '18

25 Apr '18

#8406: Invalid object in isRetainer() or Segfault ----------------------------------+---------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- When compiling with -rtsopts -threaded -prof -fprof-auto -caf-all and running with -N4 -hr I get a "Segmentation fault" every time. If I run with -N4 -qg1 -hr, I either get a segfault or internal error: Invalid object in isRetainer(): 40 When the segfault happens, it happens quickly. If the segfault doesn't happen, the program runs for about 5 seconds and I get "invalid object" error (always 40). Without -hr, I have never gotten a segfault. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8406> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files
by GHC 17 Apr '18

17 Apr '18

#9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files ------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have a package that bundles in C library sources. I never had a problem with this when using GHC 7.6. In GHC 7.8, the order of the c-sources in the cabal file now matters. Sources must be listed earlier if they have symbols that subsequently loaded object files will need. If the c-sources are in the wrong order, when running "cabal repl" I get Loading object (static) dist/build/decnumber/src/decQuad.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14294_0/ghc14294_1.so: undefined symbol: DECSTICKYTAB Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug When using the same code and cabal file with GHC 7.6, "cabal repl" works fine: GHCi loads each static object (regardless of ordering in the cabal file), links up the necessary symbols, and launches successfully. Haskell Cafe discussion here: http://www.haskell.org/pipermail/haskell-cafe/2014-May/114041.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9074> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9307: wave4main in nofib fails
by GHC 14 Apr '18

14 Apr '18

#9307: wave4main in nofib fails -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: NoFib benchmark | Version: 7.8.3 suite | Operating System: MacOS X Keywords: wave4main | Type of failure: Incorrect result Architecture: x86_64 (amd64) | at runtime Difficulty: Unknown | Test Case: wave4main Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Compiling HEAD with perf-llvm, (3.4.2) and running the nofib suite fails at the wave4main case. It is not clear to me whether wave4main should always produce the same output (and so the test fails because it does not do so) or whether the numbers generated depend on some feature of the build settings, or OS. {{{ HC = /Users/xxx/Projects/ghc/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -cpp -fglasgow-exts -rtsopts RUNTEST_OPTS = -ghc-timing ==nofib== wave4main: size of wave4main follows... __TEXT __DATA __OBJC others dec hex 4091904 450560 0 4295947176 4300489640 1005443a8 ==nofib== wave4main: time to run wave4main follows... ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; real 0m0.217s user 0m0.191s sys 0m0.011s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16932.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.197s user 0m0.186s sys 0m0.008s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16961.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.201s user 0m0.189s sys 0m0.009s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17011.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.201s user 0m0.190s sys 0m0.008s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17051.1 2014-07-13 13:43:23.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.200s user 0m0.189s sys 0m0.009s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17080.1 2014-07-13 13:43:23.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 make: *** [runtests] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9307> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3