May 2017 - ghc-tickets

[GHC] #11771: ghc.exe: `panic'! (the 'impossible' happened); thread blocked indefinitely in an MVar operation
by GHC 02 Oct '17

02 Oct '17

#11771: ghc.exe: `panic'! (the 'impossible' happened); thread blocked indefinitely in an MVar operation ----------------------------------------+------------------------------- Reporter: YoYoYonnY | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- Here's a "fun" one: {{{#!hs *Main> main Interrupted. *Main> *Main> !cl ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > ghci --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 }}} Don't mind the {{{!cl}}}, GHC crashed as soon as the interupt was registered, I usually {{{:!cls}}} after I execute main. I will backup the code in case someone wants to see if it's a bug in my program, but I didn't use multithreading myself, and I don't think the vector, unordered-containers, bytestring and parsec packages use threading either (all heavily at work, though)... The interupt was nececairy because my code was generating a infinite (oops) collection of these bad boys, using all sorts of folds, maps, etc.: {{{#!hs newtype ParserData = ParserData { unpackParserData :: HashMap ByteString (ParserData -> Either ByteString (Parser ())) } }}} I am wondering if this could be a problem with Windows, because the system was running slow at the time of the interupt; The {{{Alt+Tab}}} screen didn't appear until after the interupt. I don't think I can manage to reproduce this bug, which is unfortunate aswell (low priority because of that :c). Either way, it crashed, that's all I can tell you for sure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11771> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11963: GHC introduces kind equality without TypeInType
by GHC 02 Oct '17

02 Oct '17

#11963: GHC introduces kind equality without TypeInType -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | 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 following program is accepted by GHC 8.0 rc2 {{{ {-# LANGUAGE GADTs, PolyKinds, RankNTypes #-} data Typ k t where Typ :: (forall (a :: k -> *). a t -> a t) -> Typ k t }}} This probably shouldn't be accepted, because this is a circuitous way of saying: {{{ {-# LANGUAGE TypeInType #-} data Typ k (t :: k) = Typ }}} which does not work without `TypeInType`. Or perhaps both should be accepted without `TypeInType`? Printing with explicit kinds makes it clear why the obvious check didn't fire: {{{ ezyang@sabre:~$ ghc-8.0 --interactive B.hs -fprint-explicit-kinds GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( B.hs, interpreted ) Ok, modules loaded: Main. *Main> :info Typ type role Typ nominal nominal nominal data Typ k k1 (t :: k) where Typ :: forall k (t :: k). (forall (a :: k -> *). a t -> a t) -> Typ k k t -- Defined at B.hs:2:1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11963> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10229: setThreadAffinity assumes a certain CPU virtual core layout
by GHC 30 Sep '17

30 Sep '17

#10229: setThreadAffinity assumes a certain CPU virtual core layout -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The {{{RTS -qa}}} option that can set thread affinity was implemented in https://git.haskell.org/ghc.git/commitdiff/31caec794c3978d55d79f715f21fb729… {{{ // Schedules the thread to run on CPU n of m. m may be less than the // number of physical CPUs, in which case, the thread will be allowed // to run on CPU n, n+m, n+2m etc. void setThreadAffinity (nat n, nat m) }}} Today I discovered that on some machines, this option helps parallel performance (e.g. {{{+RTS -N4}}}) a lot, while on others it doesn't. Together with thomie on #ghc, I found out the reason: Lets assume I have 4 real cores with hyperthreading, so 8 virtual cores. The mapping of hyperthreading cores to physical cores is different across machines. On my one machine (Intel i5), the layout is 11223344, meaning that the first two vCPUs (hyperthreads) that the OS announces (visible e.g. in HTOP) map to the first physical core in the system, and so on. On my other machine (Intel Xeon), the layout is 12341234; here the 1st and the 5th vCPU map to the same physical core. This layout can be (on Linux) observed by running: {{{ cat /proc/cpuinfo|egrep "processor|physical id|core id" |sed 's/^processor/\nprocessor/g' }}} I do not know whether this layout is dictated by the processor, chosen by the OS, or even changing across reboots; what is clear is that the layout can vary across machines. Now, as explained by thomie: {{{ -qa will set your 4 capabilities to cores [(1,5), (2,6), (3,7), (4,8)], and then the os randomly chooses out of those tuples }}} This strategy is optimal for the 12341234 layout; for example, when running with -N4, it ensures that two threads are not scheduled onto vCPUs that are on the same physical core. The possible {{{+RTS -aq}}} choice {{{1__4_23_}}} is a great assignment in this case, as is {{{1234____}}} ({{{_}}} means the vCPU is not chosen). But for the 11223344, the choice {{{1234____}}} isn't good, because it uses only 2 of our 4 physical cores; our program now takes twice as long to run. ---- It seems likely to me that {{{setThreadAffinity}}} was written on a machine with 12341234 layout, and with the assumption that all machines have this layout. It would be great if we could change it to take the actual layout into account. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10941: Large heap address space breaks valgrind
by GHC 29 Sep '17

29 Sep '17

#10941: Large heap address space breaks valgrind -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.11 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9706 Differential Rev(s): | -------------------------------------+------------------------------------- It seems that programs compiled with a GHC `--enable-large-address-space` (see #9706) no longer run under valgrind, which is a pitty, as that is useful to get more reliable numbers out of nofib. It fails with `internal error: getMBlock: mmap: Invalid argument` This bug is a general “Can we do anything about this”. In particular, is there a possibility to make this a RTS option instead of a compile time option? Or maybe it is possible to talk to the valgrind authors if they can support such large allocations? If neither, can we maybe extend the error message to say “If you are using a tool like valgrind, you might want to recompile the compiler with `--disable-large-address-space.” -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10941> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11228: Interaction between ORF and record pattern synonyms needs to be resolved.
by GHC 29 Sep '17

29 Sep '17

#11228: Interaction between ORF and record pattern synonyms needs to be resolved. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, orf | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the two extensions do not work well together. When defining a record pattern synonym all field names must be distinct even with the extension turned on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11228> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13391: PolyKinds is more permissive in GHC 8
by GHC 28 Sep '17

28 Sep '17

#13391: PolyKinds is more permissive in GHC 8 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | 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: -------------------------------------+------------------------------------- The docs claim that the definition in section 9.11.10 {{{ data G (a :: k) where GInt :: G Int GMaybe :: G Maybe }}} "requires that `-XTypeInType` be in effect", but this isn't the case. The following compiles with GHC-8.0.2: {{{ {-# LANGUAGE PolyKinds, GADTs #-} data G (a :: k) where GInt :: G Int GMaybe :: G Maybe }}} The example does *not* compile with 7.10.3, so this seems to be a case where `-XPolyKinds` has become more permissive in GHC 8 (as outlined in section 9.11.1). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms
by GHC 28 Sep '17

28 Sep '17

#13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8684, #12912 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From my discovery at https://phabricator.haskell.org/D42#30542: {{{ Why does the existing code work on platforms that are not Linux? In my select man page it says: On Linux, select() modifies timeout to reflect the amount of time not slept; most other implementations do not do this. (POSIX.1-2001 per‐ mits either behavior.) This causes problems both when Linux code which reads timeout is ported to other operating systems, and when code is ported to Linux that reuses a struct timeval for multiple select()s in a loop without reinitializing it. Consider timeout to be undefined after select() returns. The existing select loop seems to rely on the fact that &tv is updated as described here. }}} Same for `man 2 poll`. E.g. `man 2 select` on FreeBSD 11 says explicitly: {{{ BUGS Version 2 of the Single UNIX Specification (``SUSv2'') allows systems to modify the original timeout in place. Thus, it is unwise to assume that the timeout value will be unmodified by the select() system call. FreeBSD does not modify the return value, which can cause problems for applications ported from other systems. }}} I have tested this now on FreeBSD, and indeed it doesn't work as expected. With GHC 7.10.2: {{{ import System.IO main = hWaitForInput stdin (1 * 1000) }}} `ghc --make test.hs -rtsopts` {{{ [root@ ~]# time ./test real 0m1.386s user 0m0.004s sys 0m0.000s [root@ ~]# time ./test +RTS -V0.01 real 0m1.386s user 0m0.001s sys 0m0.000s [root@ ~]# time ./test +RTS -V0.001 real 0m1.678s user 0m0.003s sys 0m0.002s [root@ ~]# time ./test +RTS -V0.0001 real 0m11.311s user 0m0.032s sys 0m0.139s }}} See how when we increase the timer signal, the sleep suddenly takes 10x longer than it should. That's because it triggers the case where EINTR is received in https://github.com/ghc/ghc/blob/f46369b8a1bf90a3bdc30f2b566c3a7e03672518%5E…, letting us use the same unmodified 1-second `struct timeval *timeout` again and again. This demo of the bug works for GHC 7.10 and 8.0.1; in 8.0.2 `hWaitForInput` is broken (https://ghc.haskell.org/trac/ghc/ticket/12912#comment:4) so the demo doesn't work there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13497> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #11342: Character kind
by GHC 28 Sep '17

28 Sep '17

#11342: Character kind -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: alexvieth Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- We know and love the Symbol kind, but as far as I know it's not possible to analyse a Symbol type, as we would a String term. It would be nice to have a Character kind and some related type families: {{{#!hs data Character -- Pattern match a Symbol. 'Nothing when empty, 'Just '(head, tail) -- otherwise. type family UnconsSymbol (s :: Symbol) :: Maybe (Character, Symbol) -- Put a Character at the head of a Symbol. type family ConsSymbol (c :: Character) (s :: Symbol) :: Symbol -- Work with Characters. Ideally we'd have counterparts for every -- function on Data.Char. type family ToUpper (c :: Character) :: Character type family IsAlpha (c :: Character) :: Bool }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11342> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12376: Allow function definitions in record syntax
by GHC 27 Sep '17

27 Sep '17

#12376: Allow function definitions in record syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Would it be possible to write {{{#!hs propertyMap :: (Monad m, Ord k) => v -> PropertyMap m k v propertyMap v0 = go v0 Map.empty where go v m = PropertyMap { getP = \k -> return $ maybe v id (Map.lookup k m) , putP = \k v' -> return $ go v (Map.insert k v' m) } }}} as {{{#!hs propertyMap :: (Monad m, Ord k) => v -> PropertyMap m k v propertyMap v0 = go v0 Map.empty where go v m = PropertyMap { getP k = return $ maybe v id (Map.lookup k m) , putP k v' = return $ go v (Map.insert k v' m) } }}} Simpler example `MkFoo { id = \x -> x }` as {{{#!hs MkFoo { id x = x } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9898: Couldn't match type `(Char, ())' with `()'
by GHC 27 Sep '17

27 Sep '17

#9898: Couldn't match type `(Char, ())' with `()' -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Windows Keywords: | Type of failure: GHC Architecture: x86_64 (amd64) | rejects valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- 'test3' is expected to type check given that 'test1' and 'test2' type check. 'test4' is not expected to type check. {{{ ghc_bug2.hs:24:9: Couldn't match type `(Char, ())' with `()' Expected type: Filter (Equal Int) (Char, Filter (Equal Int) ()) Actual type: () In the expression: () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) In an equation for `test2': test2 = () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) ghc_bug2.hs:28:9: Couldn't match type `(Char, ())' with `()' Expected type: Filter (Equal Int) (Char, ()) Actual type: () In the expression: () In an equation for `test3': test3 = () }}} {{{#!hs {-# LANGUAGE TypeFamilies, UndecidableInstances, DataKinds #-} module Main where type family Filter f xs where Filter f (x, xs) = ApplyFilter (f x) (x, Filter f xs) Filter f () = () -- type family ApplyFilter p xs where ApplyFilter False (x, xs) = xs ApplyFilter p xs = xs -- type family Equal x y where Equal x x = True Equal x y = False -- -- Type checks test1 :: ApplyFilter ((Equal Int) Char) (Char, Filter (Equal Int) ()) test1 = () -- Couldn't match type `(Char, ())' with `()' test2 = () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) -- Couldn't match type `(Char, ())' with `()' test3 :: Filter (Equal Int) (Char, ()) test3 = () -- Type checks, should not test4 :: Filter (Equal Int) (Char, ()) test4 = ('x', ()) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9898> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11