October 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] #14299: GHCi for GHC 8.2.1 crashed with simple function?
by GHC 02 Oct '17

02 Oct '17

#14299: GHCi for GHC 8.2.1 crashed with simple function? --------------------------------------+------------------------------- Reporter: mathiassm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- I'm a newbie here, but I'm following your instructions! I started GHCi, defined a simple factorial function and then called it and... it crashed. {{{#!hs let f 0 = 0 f n = n * f (n-1) f 0 }}} That is what I introduced in the console... After that computer hanged and gave me the following error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14299> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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] #14303: HasField ambiguity error
by GHC 01 Oct '17

01 Oct '17

#14303: HasField ambiguity error -------------------------------------+------------------------------------- Reporter: cloudhead | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Both of these functions fail to compile with the error below: {{{#!haskell {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} import Control.Monad.Reader import GHC.Records import Data.Proxy askField :: forall x a m r. (HasField x r a, MonadReader r m) => m a askField = asks (getField @x) askField' :: forall x a m r. (HasField x r a, MonadReader r m) => m a askField' = asks (getFieldWithProxy (Proxy :: Proxy x)) where getFieldWithProxy :: forall proxy. proxy x -> r -> a getFieldWithProxy = const getField }}} {{{ Test.hs:12:14: error: • Could not deduce (HasField x0 r a) from the context: (HasField x r a, MonadReader r m) bound by the type signature for: askField' :: forall x a (m :: * -> *) r. (HasField x r a, MonadReader r m) => m a at Test.hs:12:14-69 The type variable ‘x0’ is ambiguous • In the ambiguity check for ‘askField'’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: askField' :: forall x a m r. (HasField x r a, MonadReader r m) => m a | 12 | askField' :: forall x a m r. (HasField x r a, MonadReader r m) => m a | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I hope I'm not missing something, but one of these should compile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14303> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14302: ghc panic on simple program
by GHC 01 Oct '17

01 Oct '17

#14302: ghc panic on simple program -------------------------------------+------------------------------------- Reporter: aberent | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am experimenting with Haskell, and am attempting to write a simple maze solver. ghci gives meaningful errors for it, and doesn't crash, but ghc gives {{{ ~/haskell/course$ ghc tiltmaze.hs [1 of 1] Compiling Main ( tiltmaze.hs, tiltmaze.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] m'_a5Wy :: t_a5Wx[tau:1] (CHoleCan: m') [W] sx'_a5WB :: t_a5WA[tau:1] (CHoleCan: sx') [W] sy'_a5WE :: t_a5WD[tau:1] (CHoleCan: sy')} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The code is: {{{ import Data.Sequence as Sequence -- A maze is a grid of empty cells and walls -- true means wall data Maze = Seq (Seq Bool) data Direction = North | South | East | West directions = [North, South, East, West] step :: Direction -> Int -> Int -> (Int, Int) step d x y | North = (x, y-1) | South = (x, y+1) | East = (x+1, y) | West = (x-1, y) solve :: Maze -> Int -> Int -> Int -> Int -> Bool solve m sx sy tx ty | sx == tx && sy == ty = True | otherwise = let solved m x y d | x' < 0 = False | y' < 0 = False | x' >= Sequence.length m = False | y' >= Sequence.length $ m `index` x' = False | not ((m `index` x') `index` y') = False | otherwise = solve m' x' y' tx ty where (x', y') = step d m' = update y False (m `index` x) in any (solved m' sx' sy') directions }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14301: ghc: panic! (the 'impossible' happened)
by GHC 01 Oct '17

01 Oct '17

#14301: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: mcapodici | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- **When I build my program I get this:** {{{ play-0.1.0.0: build (exe) Preprocessing executable 'play' for play-0.1.0.0... [1 of 1] Compiling Main ( src/Main.hs, .stack-work/dist/x86_64 -linux-nopie/Cabal-1.24.2.0/build/play/play-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] interactD_aL2 :: t_aL1[tau:1] (CHoleCan: interactD) [W] interactD_aLt :: t_aLs[tau:1] (CHoleCan: interactD)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} **The code:** {{{ {-# LANGUAGE GADTs #-} module Main where import Control.Monad.Trans.Cont import Control.Monad.Trans.Class --main :: IO () {-- CONTT -- main = evalContT contt contt :: ContT () IO () contt = do k <- do callCC $ \exit -> do lift $ putStrLn "Entry" exit $ \_ -> do putStrLn "Exit" lift $ putStrLn "Inside" lift $ k () --} {-- class Monad m => Interact m where get :: m String say :: String -> m () instance Interact IO where get = getLine say = putStrLn prog :: Interact a => a () prog = do say "Hello what is your name?" name <- get say $ "Hello " ++ name ++ ", I am prog! Goodbye" main :: IO () main = prog --} data InteractD m = InteractD { getD :: m String , sayD :: String -> m () } interactDIO :: InteractD IO interactDIO = interactD getLine putStrLn interactDIO2 :: InteractD IO interactDIO2 = interactD (return "James") putStrLn }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14301> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

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

01 Oct '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