September 2015 - ghc-tickets

[GHC] #10817: Looping default associated type family without UndecidableInstances
by GHC 21 Oct '15

21 Oct '15

#10817: Looping default associated type family without UndecidableInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Proxy class C a where type F a type F a = F a instance C Bool x :: Proxy (F Bool) x = Proxy }}} GHC just loops. Setting a low `-ftype-function-depth` doesn't help. I actually don't terribly mind the looping (although aborting with an overflow would be better). But I don't like that it's possible without `UndecidableInstances` in sight. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10817> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10672: checkProddableBlock crash during Template Haskell linking
by GHC 21 Oct '15

21 Oct '15

#10672: checkProddableBlock crash during Template Haskell linking -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #9297 #10563 Differential Revisions: | #8237 -------------------------------------+------------------------------------- When compiling an executable that uses Template Haskell against a library that contains C++ code, GHC crashes: {{{ [2 of 2] Compiling Main ( app\Main.hs, dist\build\main\main- tmp\Main.o ) ghc.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 0000000000360564 (GHC version 7.10.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I've boiled this down into a minimal reproduction of a library that includes a .cpp file, and an executable that depends on it. To test: {{{ git clone https://github.com/lukexi/cxx-link-fail-repro cabal run }}} The crash does not occur in the repro unless I use C++ exceptions in the library, and use Template Haskell in the executable, but in the project I boiled this down from (http://github.com/lukexi/bullet-mini) the problem occurs even with {{{cc-options: -fno-exceptions}}}. Some more details are at https://github.com/lukexi/cxx-link-fail-repro The platform is Windows 8.1 under MSYS2 (GHC is still using its inbuilt mingw). I've also tried 7.10.2-RC1 with the same result. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10225: GHC does not specialize based on type equality
by GHC 21 Oct '15

21 Oct '15

#10225: GHC does not specialize based on type equality -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Based on my testing, it seems that if I have a function like f :: (v ~ V2) => v -> v this will be slower than f :: v -> v It would be great if GHC could do this optimization. The reason I want this is that I have written some very generic functions in my program, which are actually only used for one type. SPECIALIZE doesn't seem to do enough, as it's hard to get those GHC to "see" all of those types. As a compromise, I tried to tell GHC what those types actually are via type equalities, so that I can keep type constraints around for the future. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10258: internal error: evacuate: strange closure type 3269
by GHC 21 Oct '15

21 Oct '15

#10258: internal error: evacuate: strange closure type 3269 -------------------------------------------+------------------------------- Reporter: lukaramu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- When trying to load the attatched source into GHCi, it spit out the following error: {{{ ghc.exe: internal error: evacuate: strange closure type 3269 (GHC version 7.8.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} I could not reproduce the bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8957: ghci's :l -> internal error: evacuate: strange closure type 8306
by GHC 21 Oct '15

21 Oct '15

#8957: ghci's :l -> internal error: evacuate: strange closure type 8306 ----------------------------------+------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- GHCi crashes when :loading a file. Unfortunately I can't reproduce the bug, so this one's gonna be lots of information that probably will help very little. This is the actual error message: {{{ *CommonStatistics Data.List> :l SimpleCellularALife [1 of 2] Compiling CommonStatistics ( CommonStatistics.hs, interpreted ) <interactive>: internal error: evacuate: strange closure type 8306 (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} This one was the error I was working on, i.e. the (legit) error in the previous call: (Including this because it gives you a clue what I was working on, I was mostly fiddling around with parens in placeAgents' gnd function) {{{ *CommonStatistics Data.List> :l SimpleCellularALife [1 of 2] Compiling CommonStatistics ( CommonStatistics.hs, interpreted ) [2 of 2] Compiling SimpleCellularALife ( SimpleCellularALife.hs, interpreted ) SimpleCellularALife.hs:70:28: Couldn't match expected type `Array i0 e0' with actual type `Ground' In the return type of a call of `ground' In the first argument of `(!)', namely `ground (tiles w)' In the expression: (ground (tiles w) ! (fst $ head grp)) SimpleCellularALife.hs:70:36: Couldn't match expected type `Tile' with actual type `Array Coordinates Tile' In the return type of a call of `tiles' In the first argument of `ground', namely `(tiles w)' In the first argument of `(!)', namely `ground (tiles w)' Failed, modules loaded: CommonStatistics. }}} Included Source Files - CommonStatistics.hs: {{{ module CommonStatistics where type Memory = [Int]--Internal state of an Agent. data StatUpdate = StatUpdate{ newVictories :: [Int] -- by agentID } deriving (Show) data Agent = Agent{ agentID :: Int, sourcePath :: FilePath, --path to .hs source file. relative to executable doFunc :: [String] -> Memory -> (Memory, [String]), evFunc :: [String] -> Memory -> (Memory, String), personalMemory :: Memory } instance Show Agent where show (Agent { agentID = aID, sourcePath = path, doFunc = forgetit, evFunc = forgetittoo, personalMemory = mem }) = show (aID, path, mem) }}} And SimpleCellularALife.hs: (I am not exactly confident that this is the version that caused the error. I sadly can't reproduce it, so there's no confirming that. {{{ module SimpleCellularALife where import Data.Array import Data.List import System.Random import CommonStatistics data Ground = Ground { food :: Int } data Entity = Entity{ ai :: Agent, health :: Int } data Tile = Tile{ ground :: Ground, entities :: [Entity] } data World = World { tiles :: Array Coordinates Tile } type Coordinates = (Int, Int) getRandomPosition :: RandomGen t => World -> t -> (t, Coordinates) getRandomPosition w rand = let ((minx, miny), (maxx, maxy)) = bounds $ tiles w (x, rand2) = randomR (minx, maxx) rand (y, rand3) = randomR (miny, maxy) rand2 in (rand3, (x, y)) placeAgents :: RandomGen t => World -> [Agent] -> t -> (t, World) placeAgents w agents rand = let createTileUpdates (ag:ags) wrld rnd = let (rnd2, coords) = getRandomPosition wrld rnd (rnd3, restUpd) = createTileUpdates ags wrld rnd2 in (rnd3, (coords, ag) : restUpd) createTileUpdates [] wrld rnd = (rnd, []) (rand2, assocList) = createTileUpdates agents w rand groupedAssocList = groupBy (\(c1, a1) (c2, a2) -> c1 == c2) $ sortBy (\(c1, a1) (c2, a2) -> compare c1 c2) assocList gnd grp = ground ((tiles w) ! (fst $ head grp)) condenseGroup grp = (fst $ head grp, Tile{ground = gnd grp, entities = snd $ unzip grp}) --map condenseGroup groupedAssocList --::(Coordinates, Tile) in (rand, w) --placeAgents (placeAgent w firstAg x y) agents rand3 }}} Someone suggested that this might've been GHCI running out of memory. I am as of writing this at 66% out of 4GB used. The GHCI instance was opened for an extended period of time, so it might have racked up quite a bit of RAM usage. I can say though that considering the file sizes, 1.3GB of RAM usage seems unreasonable. And because I haven't yet written enough, here are all the variations of the line I was working on that could've caused it. Pulled them out of my text editor's buffer. {{{ gnd grp = (ground (tiles w) ! fst $ head grp) gnd grp = (ground (tiles w) ! (fst $ head grp) gnd grp = (ground (tiles w) ! (fst $ head grp)) gnd grp = (ground ((tiles w) ! (fst $ head grp)) gnd grp = ground ((tiles w) ! (fst $ head grp)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8957> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8687: Strange closure type 9983
by GHC 21 Oct '15

21 Oct '15

#8687: Strange closure type 9983 ------------------------------------+------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- {{{ *Main> :main C:\\Windows\\Media\\onestop.mid <interactive>: internal error: evacuate: strange closure type 9983 (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} This happened to me on {{{ghci playmidi.hs}}} from the {{{examples/}}} folder of {{{http://hackage.haskell.org/package/hmidi-0.2.1.0}}} (downloaded the tar and fixed the parsec import, removing the {{{"parsec2"}}} package import and fixing a type checking error, replacing {{{selectOutputDevice Nothing}}} by {{{selectOutputDevice "Select midi output device" Nothing}}}. (We also fixed those compile errors at https://github.com/vahokif/hmidi/tree/2124a8.) I have not been able to reproduce it since the first time :( -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8687> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10319: Eta expand PAPs
by GHC 20 Oct '15

20 Oct '15

#10319: Eta expand PAPs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- SPJ writes in ticket:10260#comment:11: But see this note in SimplUtils: {{{ Note [Do not eta-expand PAPs] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We used to have old_arity = manifestArity rhs, which meant that we would eta-expand even PAPs. But this gives no particular advantage, and can lead to a massive blow-up in code size, exhibited by Trac #9020. Suppose we have a PAP foo :: IO () foo = returnIO () Then we can eta-expand do foo = (\eta. (returnIO () |> sym g) eta) |> g where g :: IO () ~ State# RealWorld -> (# State# RealWorld, () #) But there is really no point in doing this, and it generates masses of coercions and whatnot that eventually disappear again. For T9020, GHC allocated 6.6G beore, and 0.8G afterwards; and residency dropped from 1.8G to 45M. But note that this won't eta-expand, say f = \g -> map g Does it matter not eta-expanding such functions? I'm not sure. Perhaps strictness analysis will have less to bite on? }}} The worse code for the un-eta-expanded code for last is perhaps an example of the last paragraph! And yet the comment is reasonably convincing. I'm not sure what to do here. One thing that might be worth trying is to eta-expand as far as poss without bumping into a coercion. That would expand last but not foo. Want to try that? We may fix last but there are sure to be other cases, and the more robust the optimisations the better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10350: Should be able to specify path for eventlog output.
by GHC 20 Oct '15

20 Oct '15

#10350: Should be able to specify path for eventlog output. -------------------------------------+------------------------------------- Reporter: literon | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently it is a fixed path, but the binary might run in an env where write access is restricted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10350> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10457: Revise/remove custom mapM implementation for lists
by GHC 20 Oct '15

20 Oct '15

#10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: | Version: 7.10.1 libraries/base | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Recently, Simon Marlow asked why the list instance for Traversable had a custom mapM implementation that used the Monad operations. Having looked a bit, I don't think there's any good reason. The only fusion that the custom mapM can participate in is due to it being written as foldr, but traverse is, as well. So as long as 'mapM = traverse' is able to inline appropriately, there should be no difference. Further, this can be changed, in principle, for 7.10.2. It doesn't change any types, only the implementation. mapM = traverse is the class default definition, so this could possibly be completed by just removing the custom definition. Link to the libraries thread: https://mail.haskell.org/pipermail/libraries/2015-May/025708.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10457> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #10380: "thread blocked indefinitely" exception while blocking on a socket
by GHC 20 Oct '15

20 Oct '15

#10380: "thread blocked indefinitely" exception while blocking on a socket -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/base | Operating System: Linux Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- First start a TCP server, e.g. nc. {{{ % nc localhost -l 1234 > /dev/null }}} On another shell, compile the following program and run it: {{{ % ghc -threaded sock.hs % ./sock localhost 1234 receiver: thread blocked indefinitely in an MVar operation }}} {{{#!hs {-# LANGUAGE ViewPatterns #-} import Control.Applicative -- GHC 7.8 compatibility import Control.Concurrent import qualified Control.Exception as Ex import Control.Monad import qualified Data.ByteString.Char8 as S import Network.Socket import qualified Network.Socket.ByteString as Sock import Network.BSD (getHostByName, hostAddresses) import System.Environment import System.Mem main :: IO () main = do [host, read -> fromInteger -> port] <- getArgs sock <- connectTo host port forkVerbose "sender" $ forever $ do _ <- Sock.send sock $ S.replicate 40000 '0' return () forkVerbose "receiver" $ forever $ do dat <- Sock.recv sock 2048 putStrLn $ "received: " ++ show dat forever $ do threadDelay 1000000 performGC forkVerbose :: String -> IO () -> IO () forkVerbose name act = void $ forkIO $ do act; msg "exiting normally" `Ex.catch` \e -> msg $ show (e :: Ex.SomeException) where msg s = putStrLn $ name ++ ": " ++ s connectTo :: HostName -> PortNumber -> IO Socket connectTo hostName port = do addr <- SockAddrInet port <$> lookupHost hostName sock <- socket AF_INET Stream 0 connect sock addr return sock lookupHost :: String -> IO HostAddress lookupHost name = do hostInfo <- getHostByName name case hostAddresses hostInfo of [] -> error ("Invalid host name: " ++ name) (a:_) -> return a }}} GHC 7.8.3 doesn't have this problem. I suspect that this is a regression in the event manager. When there is an event, `GHC.Event.Manager.onFdEvent` seems to remove all callbacks associated to the `fd`, whether or not they match the current event. In the program above, the callback for `recv` may be removed permanently when the socket becomes ready for `send`ing, causing the "receiver" thread to deadlock. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8