August 2015 - ghc-tickets

[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

[GHC] #10388: GHC panic when compiling Yesod app
by GHC 20 Oct '15

20 Oct '15

#10388: GHC panic when compiling Yesod app -------------------------------------+------------------------------------- Reporter: chfi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When compiling a Yesod app, using 'yesod devel', GHC crashes with the following error: {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/yb/98yhr6bj5fg3z68prq2gxs6w0000gn/T/ghc99761_0/libghc99761_51.dylib, 5): Symbol not found: _adverzuGWP0VNzzhgmvBNANratclKO_SubscriptionType_zdfPersistFieldKey_closure Referenced from: /var/folders/yb/98yhr6bj5fg3z68prq2gxs6w0000gn/T/ghc99761_0/libghc99761_51.dylib Expected in: flat namespace in /var/folders/yb/98yhr6bj5fg3z68prq2gxs6w0000gn/T/ghc99761_0/libghc99761_51.dylib }}} Specifically, I'm using Yesod's mkPersist to create a data type, and it works fine, until I make said type an instance of FromJSON, in which case the above panic occurs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10388> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10390: Constraint order must match with RankNTypes
by GHC 20 Oct '15

20 Oct '15

#10390: Constraint order must match with RankNTypes -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the following code, GHC will not compile unless the constraints on the higher-rank function have the same *order* as the method declaration in `ApPair`. {{{#!hs {-# LANGUAGE RankNTypes #-} class ApPair r where apPair :: (forall a . (ApPair a, Num a) => Maybe a) -> Maybe r instance (ApPair a, ApPair b) => ApPair (a,b) where apPair = apPair' apPair' :: (ApPair b, ApPair c) => (forall a . (ApPair a, Num a) => Maybe a) -> Maybe (b,c) apPair' f = let (Just a) = apPair f (Just b) = apPair f in Just $ (a, b) }}} That is, the following does *not* compile: {{{#!hs apPair' :: (ApPair b, ApPair c) => (forall a . (Num a, ApPair a) => Maybe a) -> Maybe (b,c) apPair' f = let (Just a) = apPair f (Just b) = apPair f in Just $ (a, b) }}} GHC probably shouldn't care about lexical matching when checking constraints. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10390> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8648: Initialization of C statics broken in threaded runtime
by GHC 20 Oct '15

20 Oct '15

#8648: Initialization of C statics broken in threaded runtime ------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider a tiny package `static-value`, consisting of one Haskell file {{{ foreign import ccall unsafe "returnStaticValue" c_returnStaticValue :: IO CInt printStaticValue :: IO () printStaticValue = print =<< c_returnStaticValue }}} and one corresponding C file {{{ static int theStaticValue = 0; int returnStaticValue() { // Modify the static so the C compiler doesn't optimize it away return theStaticValue++; } }}} (test case is attached). If we call `printStaticValue` using the GHC API: {{{ runGhc (Just libdir) $ do flags0 <- getSessionDynFlags void $ setSessionDynFlags flags0 { hscTarget = HscInterpreted , ghcLink = LinkInMemory , ghcMode = CompManager } setContext $ [ IIDecl $ simpleImportDecl $ mkModuleName "StaticValue" ] _ <- runStmt "StaticValue.printStaticValue" RunToCompletion }}} then we see "0", as expected. However, if we compile this code using the threaded runtime, and we wrap the above code in a call to either `forkIO` or `forkOS`, then we see a different value printed (-907777, whatever that value is). Some notes: * I have been unable to reproduce this bug without using GHC as API; in particular, calling `printStaticValue` directly, wrapped in `forkIO` or `forkOS` or not, always works as expected. * If I change the initialization value of `staticValue` from 0 to anything else (say, 1234), we always get the right answer, never the uninitialized value. Presumably this is because non-zero values require some explicit code to be run (and it does get run), while a zero value gets initialized differently (and apparently, that's where the bug is). * I have reproduced this bug in both ghc 7.4 and 7.7.20131227. This ticket is the result of tracking down a problem with calling `createProcess` from within the GHC API, which would cause the parent process to stall. As it turns out, `runProcess.c` (from the `process` library) declares a `static long max_fd = 0`, and in `runInteractiveProcess` checks for this value to be 0, and if it is, does a syscall to figure out what the maximum FD is. But since this static does not get initialized properly (the bug reported in this ticket), it gets left at its (random? but always the same) value (281474975802879), so that the child process proceeds to close rather too many file descriptors (if close_fds was set to True) and the parent stalls. Indeed, changing the initialization to `static long max_fd = -1` (and adjusting the later check for zero accordingly) fixes this (so this is a viable workaround in `process` if we cannot track down the bug in GHC). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10650: Can't define GHCi :def macro with NoImplicitPrelude on
by GHC 20 Oct '15

20 Oct '15

#10650: Can't define GHCi :def macro with NoImplicitPrelude on -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #8640 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- GHCi is unusually prohibitive in typechecking {{{:def}}} macros when {{{NoImplicitPrelude}}} is enabled. Here's an example to illustrate what I mean: {{{ $ ghci -XNoImplicitPrelude GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help λ> :def pf \str -> Prelude.return Prelude.$ ":! pointfree \"" Prelude.++ str Prelude.++ "\"" <interactive>:1:111: Not in scope: type constructor or class ‘String’ <interactive>:1:121: Not in scope: type constructor or class ‘IO’ <interactive>:1:124: Not in scope: type constructor or class ‘String’ }}} I can understand the functions being out-of-scope when {{{NoImplicitPrelude}}} is on, but the type errors don't make any sense to me, especially since {{{:t}}} seems to pick up on the types just fine: {{{ λ> :t Prelude.return Prelude.return :: GHC.Base.Monad m => a -> m a λ> :t "\"" "\"" :: [GHC.Types.Char] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3