June 2014 - ghc-tickets

[GHC] #8245: ghc-pkg list prints packages in non-alphabetical order
by GHC 07 Dec '15

07 Dec '15

#8245: ghc-pkg list prints packages in non-alphabetical order ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Instead, it prints the ones with the smallest version first. That does not make much sense. I will attach a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9015: A documented way to differentiate between statements, declarations, imports, etc.
by GHC 07 Dec '15

07 Dec '15

#9015: A documented way to differentiate between statements, declarations, imports, etc. -------------------------------------+------------------------------------- Reporter: splinterofchaos | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Moderate (less | bug than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I'm working on a little REPL and the GHC API seems to supply two functions for evaluating one line, without compiling and evaluating into an `HValue`, which doesn't seem to have an `Outputable` instace: `runStmt` and `runDecls`. As it turns out, I need slightly different code to run on declarations verses statements, so this makes sense, but given a random string from the user, how can I tell the difference? I don't see anything in the documentation about this. I took a look at ghci's source (https://github.com/ghc/ghc/blob/a6f2c852d49313fa8acea2deb3741ab86c6ef995/gh…] and it looks like they just peek at the first word of the input, and that may be correct and sufficient, but impossible to verify without looking at Haskell's grammar. But even if I did verify it, that doesn't make explicit the difference between what `runDecls` and `runStmt` will accept. For a contrived example, consider if GHC implemented a feature that allowed for a new type of decl. It might be enabled by a language extension which means that testing whether a string is a statement or declaration cannot be done purely as we have to check the dynflags. Furthermore, the client may not be aware of the extension and thus send the input to `runStmt` instead. It would seem to me that requiring the user to manually parse the input violates separation of concerns since truly GHC knows best what source GHC will accept. The user should not have to examine the input except for if they need to modify or interpret it as something other than Haskell source code. The GHC API should either document an example function for differentiating declarations from statements (and even import statements), supply one itself, or supply several along the lines of `isDecl, isStmt, isImport :: String -> Bool`. This would improve ease-of-use by making client code more obvious and correct. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9015> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8582: Record syntax for pattern synonyms
by GHC 03 Dec '15

03 Dec '15

#8582: Record syntax for pattern synonyms ------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Implement syntax for {{{ pattern Cons{car, cdr} = (car, cdr) }}} which can then be used just like a regular record constructor, so the following are all valid patterns: {{{ Cons (Just x) [] Cons{car = Just x} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8582> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8098: Faulty Word64 arithmetic if optimized
by GHC 02 Dec '15

02 Dec '15

#8098: Faulty Word64 arithmetic if optimized ----------------------------+--------------------------------- Reporter: achp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+--------------------------------- The following program produces different results depending on optimization: Checked.hs: {{{ module Checked ((.-.)) where (.-.) :: (Bounded a, Integral a) => a -> a -> Maybe a x .-. y | x >= 0 && y < 0 = if z > x then Just z else Nothing | x >= 0 = if z <= x then Just z else Nothing | x < 0 && y > 0 = if z < x then Just z else Nothing | otherwise = Just z where z = x - y }}} Main.hs: {{{ module Main (main) where import Data.Maybe import Data.Word import Numeric import Checked main :: IO () main = print $ showHex (fromJust ((0xFFFFFFFF00000000 :: Word64) .-. 0x00000000FFFFFFFF)) "" }}} {{{ D:\dev\haskell\ch1>ghc --make Checked.hs Main.hs [1 of 2] Compiling Checked ( Checked.hs, Checked.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... D:\dev\haskell\ch1>Main.exe "fffffffe00000001" D:\dev\haskell\ch1>del *.hi *.o *.exe D:\dev\haskell\ch1>ghc --make -O2 Checked.hs Main.hs [1 of 2] Compiling Checked ( Checked.hs, Checked.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... D:\dev\haskell\ch1>Main.exe "fffe00000001" D:\dev\haskell\ch1> }}} The bug disappears if definition and usage of (.-.) are in the same module. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8079: Redo T7919 with a cabal file
by GHC 21 Nov '15

21 Nov '15

#8079: Redo T7919 with a cabal file -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Compile-time Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Right now T7919 fails because the new dynamic-by-default GHC means that Template Haskell must be built with dynamic; of course, GHC isn't clever enough to figure this out. If we Cabalize the test, the example should start building again (and if they don't, well, that's a bug!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8079> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8199: Get rid of HEAP_ALLOCED
by GHC 21 Nov '15

21 Nov '15

#8199: Get rid of HEAP_ALLOCED ----------------------------------------------+---------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- This bug is to track progress of removing HEAP_ALLOCED from GHC, promising faster GC, as long as we can keep the cost of indirections down. The relevant wiki article: http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced ; we are implementing method 2. The attached patchset is *almost* able to support GHC itself; a ghc-stage2 built this way can compile most files, but is much slower in some cases, and probably has some correctness bugs. Improvements possible: * Don't pay for a double indirection when -fPIC is turned on. Probably the easiest way to do this is to *not* bake in the indirections into compiled code when it is -fPIC'd, and instead scribble over the GOT. However, I don't know how to go backwards from a symbol to a GOT entry, so we might need some heinous assembly hacks to get this working. * Closure tables should have their indirections short-circuited by the initialization code. * We are paying an indirection when a GC occurs when the closure is not in R1. According to the wiki page, technically this is not needed, but I don't know how to eliminate references to the closure itself from stg_gc_fun. * Properly handle the Windows DLL case (e.g. SRTs); this should be simpler now that everything is an indirection. * Bikeshed hs_main API changes (because closures are not valid prior to RTS initialization, so you have to pass in an indirection instead) * Improve static indirection and stable pointer registration, avoiding binary bloat from `__attribute(constructor)__` stubs. * Need to implement a new megablock tracking structure so we can free/check for lost blocks -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52

[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] #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] #9058: System.IO.openTempFile does not scale
by GHC 07 Oct '15

07 Oct '15

#9058: System.IO.openTempFile does not scale ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In search of a bug in darcs http://bugs.darcs.net/issue2364 i've notice very bad property of openTempFile: it's pattern is very predictable and has O(n^2) of already created temp files. Predictability allows very fun bugs survive in buggy programs, like: {{{ thread1: (fn, fh) <- openTempFile "." "hello" renameFile fn "something" -- some time after when (some_rare_buggy_condition) $ -- oops, reused temp name, but too late, other thread killed it writeFileFile fn thread2: (fn, fh) <- openTempFile "." "hello" workWithFn fn -- nobody should touch it, right? }}} It's _very_ hard to debug data corruption when all temp files are named "foo${pid}" and sometimes "foo${pid+1}". And more serious bug: the more threads you have trying to create similar temps performance drops significantly: Attached program shows the following numbers: {{{ $ time ./bench-temps same 2000 real 0m2.795s user 0m1.516s sys 0m1.190s $ time ./bench-temps diff 2000 real 0m0.161s user 0m0.043s sys 0m0.115s }}} It's O(N^2) growing open() storm. https://github.com/ghc/ghc/blob/master/libraries/base/System/IO.hs#L465 {{{ FileExists -> findTempName (x + 1) }}} This is the source of the problem. I'd suggest always using random name for it. For portability reasons I suggest adding at least insecure random '''rand()''' value from C library. That way we will succeed in opening temp file at the first attempt. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7