May 2018 - ghc-tickets

[GHC] #15065: T12903(profasm) produces a heap profile with out of sequence samples
by GHC 17 May '18

17 May '18

#15065: T12903(profasm) produces a heap profile with out of sequence samples -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: T12903(profasm) | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ cd testsuite && make TEST="T12903" WAY="profasm" CLEANUP=0 ; cd .. [...] =====> T12903(profasm) 1 of 1 [0, 0, 0] cd "./rts/T12903.run" && "/home/alp/WT/ghc-slow-validate/inplace/test spaces/ghc-stage2" -o T12903 T12903.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 -O -prof -static -fprof-auto cd "./rts/T12903.run" && ./T12903 +RTS -hc -p -RTS cd "./rts/T12903.run" && "/home/alp/WT/ghc-slow-validate/inplace/test spaces/hp2ps" T12903 hp2ps error when processing heap profile for T12903 *** unexpected failure for T12903(profasm) [...] $ inplace/test\ \ \ spaces/hp2ps testsuite/tests/rts/T12903.run/T12903 hp2ps: testsuite/tests/rts/T12903.run/T12903.hp, line 9, samples out of sequence $ cat testsuite/tests/rts/T12903.run/T12903.hp JOB "T12903 +RTS -hc -p" DATE "Wed Apr 18 11:59 2018" SAMPLE_UNIT "seconds" VALUE_UNIT "bytes" BEGIN_SAMPLE 0.000000 END_SAMPLE 0.000000 BEGIN_SAMPLE 0.004175 END_SAMPLE 0.004175 BEGIN_SAMPLE 0.000462 END_SAMPLE 0.000462 }}} This seems like an actual problem, completely unrelated to #12903, so I'm opening this ticket to track/fix this issue. I'll also mark T12903 as expected broken for the `profasm` way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15065> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature
by GHC 17 May '18

17 May '18

#15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple PartialTypeSignatures | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following GHCi session: {{{ $ ghci GHCi, version 8.4.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import Data.Type.Coercion λ> foo :: _ => Coercion a b; foo = Coercion <interactive>:2:8: error: • Found type wildcard ‘_’ standing for ‘Coercible a b :: TYPE ('GHC.Types.TupleRep '[])’ Where: ‘a’, ‘b’ are rigid type variables bound by the inferred type of foo :: Coercible a b => Coercion a b at <interactive>:2:27-40 To use the inferred type, enable PartialTypeSignatures • In the type signature: foo :: _ => Coercion a b λ> :set -fprint-explicit-kinds λ> foo :: _ => Coercion a b; foo = Coercion <interactive>:4:8: error: • Found type wildcard ‘_’ standing for ‘(a :: *) ~~ (b :: *) :: TYPE ('GHC.Types.TupleRep ('[] GHC.Types.RuntimeRep))’ Where: ‘a’, ‘b’ are rigid type variables bound by the inferred type of foo :: ((a :: *) ~~ (b :: *)) => Coercion * a b at <interactive>:4:27-40 To use the inferred type, enable PartialTypeSignatures • In the type signature: foo :: _ => Coercion a b }}} There are two things quite strange about this: 1. In both error messages, GHC claims that `Coercible a b`/`a ~~ b` has kind `TYPE (TupleRep '[])`. This is wrong, and should be `Coercible`. 2. For some reason, enabling `-fprint-explicit-kinds` causes the inferred constraint to be `(~~)` instead of `Coercible`, which is just plain wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15039> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15159: Expand compatibility note for readMVar
by GHC 17 May '18

17 May '18

#15159: Expand compatibility note for readMVar -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, the note reads > Compatibility note: Prior to base 4.7, readMVar was a combination of takeMVar and putMVar. This mean that in the presence of other threads attempting to putMVar, readMVar could block. Furthermore, readMVar would not receive the next putMVar if there was already a pending thread blocked on takeMVar. The old behavior can be recovered by [...] I don't think this goes quite far enough. Consider the following scenario: {{{#!hs main = do mv <- newEmptyMVar forkIO $ putMVar mv "a" >> ... >> takeMVar mv >>= ... forkIO $ putMVar mv "b" >> ... >> takeMVar mv >>= ... ... readMVar mv }}} (assume none of the ...s touch `mv`) With the current implementation of `readMVar`, each child thread will put its value in the `MVar` and then take that same value out. They may do so in either order, and the order will determine what value the main thread reads. With the ''old'' implementation of `readMVar`, there are two additional (symmetrical) possibilities. In one, the first child puts `"a"`, the main thread takes `"a"`, the second child puts `"b"`, the first child takes `"b"`, the main thread puts `"a"`, and the second child takes `"a"`. So the old version of `readMVar` could make an interaction between other threads substantially less deterministic. I believe the note should probably reflect that. Its language also could really use some clarification in general. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15159> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13167: GC and weak reference finalizers and exceptions
by GHC 16 May '18

16 May '18

#13167: GC and weak reference finalizers and exceptions -------------------------------------+------------------------------------- Reporter: Yuras | 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: -------------------------------------+------------------------------------- When GC runs a number of finalizers in a row, and the first of them throws an exception, then other finalizers are ignored. The relevant piece of code is [https://github.com/ghc/ghc/blob/fb4092642f057f258d07cd6979925f4e2579eda6/li… here]. The following program reproduces the issue: {{{ import Data.IORef import Control.Monad import Control.Exception import System.Mem main :: IO () main = do run run run run performMajorGC performMajorGC run :: IO () run = do ref <- newIORef () void $ mkWeakIORef ref $ do putStr "." throwIO $ ErrorCall "failed" }}} I expect it to output "....", but I get only "." The issue makes it unsafe to rely on finalizer for resource cleanup because unrelated finalizer (e.g. from some other library) may prevent your finalizer from running. Actually I was sure the issue is known, but today I tried to find a reference to it, and failed. If it is by design, then it should be documented somewhere. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13167> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[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] #15156: Show instances for types exported from the ghc package
by GHC 16 May '18

16 May '18

#15156: Show instances for types exported from the ghc package -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- In order to test and debug code that depends on the `ghc` package, it would be nice to have `Show` instances for the types it exports. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15156> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #913: instance Ord (StableName a)
by GHC 15 May '18

15 May '18

#913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Implemented as a custom prim so there is no risk of the gc gap? That'd fix the soundness concern. I'd for some reason mentally parsed Simon's suggestion as happening in "user land" as it were but that fixes it. I still think it falls into wontfix territory for the other reasons specified; I don't particularly _like_ our current implementation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/913#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2207: Load the interface details for GHC.* even without -O
by GHC 15 May '18

15 May '18

#2207: Load the interface details for GHC.* even without -O -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Azel Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.8.2 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Azel): * owner: (none) => Azel -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2207#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #913: instance Ord (StableName a)
by GHC 15 May '18

15 May '18

#913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I agree with your concern that an Ord instance limits future possibilities to modify the implementation. I disagree with the concern about soundness. As you point out, using hashStableName to implement an Ord instance is unsound. We do not use it in the Eq instance, and it would be every bit as unsound in an Ord instance. The path forward to implementing an Ord instance would be to introduce a new primop for comparing StableName#. It would basically be the same thing as eqStableName#. After all, eqStableName# is basically ( in the current implementation) two calls to stableNameToInt# with the guarantee that garbage collection cannot happen between them. And this guarantee that garbage collection doesn’t happen between the two calls is exactly what you make the implementation you discuss above sound. But yes, it does constrain the possible available implementations. I certainly agree with that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/913#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15133: Make `nofib` work with Hadrian
by GHC 15 May '18

15 May '18

#15133: Make `nofib` work with Hadrian -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: NoFib | Version: benchmark suite | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hadrian puts its build output in different places than the make-based build system; but nofib has the make-based paths (`inplace/bin/ghc- stage2`) hardcoded into it. It would be nice to provide a convenient way of making it work out of the box, ideally by detecting a Hadrian-built GHC and changing the paths accordingly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15133> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2