December 2016 - ghc-tickets

[GHC] #11485: Very unhelpful message resulting from kind mismatch
by GHC 06 Dec '16

06 Dec '16

#11485: Very unhelpful message resulting from kind mismatch -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code: {{{#!hs module Foo where import Data.Typeable tyConOf :: Typeable a => Proxy a -> TyCon tyConOf = typeRepTyCon . typeRep tcList :: TyCon tcList = tyConOf (Proxy :: Proxy []) }}} fails because `-XPolyKinds` is not enabled. But the error message that you get is quite different on GHC 7.10 and 8.0. On GHC 7.10.3: {{{ [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Foo.hs:9:19: Couldn't match kind ‘* -> *’ with ‘*’ Expected type: Proxy a0 Actual type: Proxy [] In the first argument of ‘tyConOf’, namely ‘(Proxy :: Proxy [])’ In the expression: tyConOf (Proxy :: Proxy []) In an equation for ‘tcList’: tcList = tyConOf (Proxy :: Proxy []) }}} But on GHC 8.0.1-rc1: {{{ Foo.hs:9:19: error: • Expected kind ‘Proxy []’, but ‘Data.Proxy.Proxy :: Proxy []’ has kind ‘Proxy []’ • In the first argument of ‘tyConOf’, namely ‘(Proxy :: Proxy [])’ In the expression: tyConOf (Proxy :: Proxy []) In an equation for ‘tcList’: tcList = tyConOf (Proxy :: Proxy []) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11485> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 06 Dec '16

06 Dec '16

#7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: Resolution: | Keywords: thread-local | state, TLS clang Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: 7678 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning since the solution isn't clear and no one has stepped up to handle this. If you are affected by this issue please do pick it up! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:56> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4505: Segmentation fault on long input (list of pairs)
by GHC 06 Dec '16

06 Dec '16

#4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: niteria => * milestone: 8.2.1 => 8.0.2 Comment: De-milestoning since the solution isn't clear and no one has stepped up to handle this. If you are affected by this issue please do pick it up! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4505#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12934: Testsuite driver buffering behavior has changed with Python 3
by GHC 06 Dec '16

06 Dec '16

#12934: Testsuite driver buffering behavior has changed with Python 3 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | 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: -------------------------------------+------------------------------------- The buffering behavior of the testsuite driver has changed with the move to Python 3 (#9184). Now output seems to arrive at the terminal in blocks. This is strange since the documentation for `sys.stdout` in Python 3.5 claims, > When interactive, standard streams are line-buffered. Otherwise, they are block-buffered like regular text files. You can override this value with the `-u` command-line option. It would be good to understand why this is the case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12934> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5553: sendWakeup error in simple test program with MVars and killThread
by GHC 06 Dec '16

06 Dec '16

#5553: sendWakeup error in simple test program with MVars and killThread -------------------------------------+------------------------------------- Reporter: bit | Owner: Type: bug | Status: new Priority: high | Milestone: 7.4.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by basvandijk): * cc: basvandijk, simonmar (added) * status: closed => new * version: 7.2.1 => 8.0.1 * resolution: worksforme => * owner: tibbe => Comment: In a program at work I get exactly the same error. I'm on '''GHC-8.0.1'''. I'm using Don Stewarts [http://hackage.haskell.org/package/ghc-gc-tune ghc-gc-tune] to find the optimal GC settings for a server program. `ghc- gc-tune` expects the program to terminate. Since it's a server this doesn't happen. To fix this I wrap the program in `timeout --preserve- status 5` to terminate the server after 5 seconds. `ghc-gc-tune` will run the program many times with different `-H` and `-A` settings. Among other things, the program forks a thread which basically does the same thing as the `serverThread` of the OP: {{{ tid <- forkIO $ forever $ threadDelay 5000000 }}} The program ends with installing a signal handler for SIGTERM which will unlock a lock that the program is waiting on. Finally the forked thread is killed: {{{ lock <- newEmptyMVar installHandler sigTERM (Catch $ putMVar lock ()) (Just fullSignalSet) takeMVar lock killThread tid }}} I believe the `sendWakeup` exception is thrown in `threadDelay`. I'm trying to reduce to program so it doesn't contain any proprietary code but so far I'm not succeeding. It appears that [https://github.com/ghc/ghc/blob/ghc-8.0/libraries/base/GHC/Event/TimerManag… closeControl] is called before [https://github.com/ghc/ghc/blob/ghc-8.0/libraries/base/GHC/Event/TimerManag… wakeManager]. Could it be that the `state` IORef is [https://github.com/ghc/ghc/blob/ghc-8.0/libraries/base/GHC/Event/TimerManag… finalized] before we run `wakeManager`? If so, how can we ensure the garbage collector treats the IORef as reachable until after `wakeManager`? Maybe writing to it, as in: {{{ wakeManager :: TimerManager -> IO () wakeManager mgr = do sendWakeup (emControl mgr) atomicWriteIORef (emState mgr) $ \x -> (x, ()) }}} ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5553#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
by GHC 06 Dec '16

06 Dec '16

#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure -------------------------------------+------------------------------------- Reporter: AntoineLatter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning since the solution isn't clear and no one has stepped up to handle this. If you are affected by this issue please do pick this up! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4144#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12930: DDEBUG build broken
by GHC 06 Dec '16

06 Dec '16

#12930: DDEBUG build broken -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- {{{ Again, Travis is failing to build master since a while. Unfortunately, only the author of commits get mailed by Travis, so I did not notice it so far. But usually, when Travis reports a build failure, this is something actionable! If in doubt, contact me. The breakage at the moment occurs only with -DDEBUG on: Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161118 for x86_64-unknown-linux): No match in record selector is_iloc Please report this as a GHC bug: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haskell… *** unexpected failure for rn017(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161118 for x86_64-unknown-linux): No match in record selector is_iloc Please report this as a GHC bug: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haskell… *** unexpected failure for T7672(normal) And started appearing, unless I am mistaken, with From: Matthew Pickering < matthewtpickering(a)gmail.com > Date: Fri, 18 Nov 2016 16:28:30 +0000 Subject: [PATCH] Optimise whole module exports We directly build up the correct AvailInfos rather than generating lots of singleton instances and combining them with expensive calls to unionLists. There are two other small changes. * Pushed the nubAvails call into the explicit export list branch as we construct them correctly and uniquely ourselves. * fix_faminst only needs to check the first element of the export list as we maintain the (yucky) invariant that the parent is the first thing in it. Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: simonpj, thomie, niteria Differential Revision: https://phabricator.haskell.org/D2657 Matthew, can you verify that this is a regression introduce here? Greetings, Joachim }}} The failing tests are `rn017` and `T7672`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12930> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12933: Wrong class instance selection with Data.Kind.Type
by GHC 06 Dec '16

06 Dec '16

#12933: Wrong class instance selection with Data.Kind.Type -------------------------------------+------------------------------------- Reporter: julm | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you consider the following code: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE FlexibleInstances #-} module Bug where import GHC.Exts (Constraint) import Data.Kind -- | Partial singleton for a kind type. data SKind k where SKiTy :: SKind Type SKiCo :: SKind Constraint instance Show (SKind k) where show SKiTy = "*" show SKiCo = "Constraint" class IKind k where kind :: SKind k instance IKind Constraint where kind = SKiCo }}} Then, the main below will compile even though there is no (IKind Type) instance, and it will print "Constraint" two times, instead of an expected "Constraint" then "*": {{{#!hs main :: IO () main = do print (kind::SKind Constraint) print (kind::SKind Type) }}} And, the main below will print "*" two times, instead of an expected "*" then "Constraint": {{{#!hs instance IKind Type where kind = SKiTy main :: IO () main = do print (kind::SKind Type) print (kind::SKind Constraint) }}} This can be worked around by replacing Type with a new data type Ty to select the right class instances, using two type families Ty_of_Type and Type_of_Ty, as done in the attached Workaround.hs. Sorry if this bug has already been fixed in HEAD: I was unable to find neither a bug report similar, nor a Linux x86_64 build of HEAD for me to test. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #3231: Permission denied error with runProcess/openFile
by GHC 06 Dec '16

06 Dec '16

#3231: Permission denied error with runProcess/openFile -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 6.10.4 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9775 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * related: => #9775 Comment: I'll operate on the assumption that these two are related. Mainly because the first few examples here had a call out to a cygwin program or something with a call to `_exec`. In which case `WaitForSingleObject` does not do what you expect. I am fixing this is `process`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3231#comment:54> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch
by GHC 06 Dec '16

06 Dec '16

#4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch ----------------------------------+-------------------------------------- Reporter: dleuschner | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * status: infoneeded => new -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4820#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0