- ghc-tickets - Haskell.org

[GHC] #11041: EventLog write fails if entire buffer is not written
by GHC 04 Nov '15

04 Nov '15

#11041: EventLog write fails if entire buffer is not written -------------------------------------+------------------------------------- Reporter: sseverance | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: eventlog | 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: -------------------------------------+------------------------------------- Recently I was trying to use ThreadScope to run down a performance issue. I ran into what I believe is a corner case with flushing the eventlog data to disk. The program was generating hundreds of millions of events every few minutes. The function printAndClearEventBuf uses fwrite to flush the buffer to disk. What I observed is that with larger buffers it would only succeed in writing the first 4096 bytes. After it would print out its debugBelch message a number of times the program would crash. It does not crash if not run with the eventlog -l flag. My understanding is that fwrite might need to be called in a loop to ensure that all data is written. fwrite is not guaranteed to always write the entire requested buffer. I don't have a good test case for this, but if there is agreement about potential issues with flushing the buffer I am more than happy to provide a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11041> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2
by GHC 04 Nov '15

04 Nov '15

#10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Windows Keywords: windows, | Type of failure: Runtime crash exceptions | Blocked By: Architecture: x86 | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- We have found a very strange RTS bug that only manifests on some Windows machines, running Windows Server 2008 R2. It does not occur on our Windows 7 machines. We are not sure whether the installed version of Visual C runtime system matters. The context is a ghc-compiled executable, that calls a function from a C++ DLL. The C++ function throws an exception internally, then catches it, and returns normally. The symptom of the bug is that, from ghc-7.8.1 onwards, including ghc-7.10.1, the C++ exception is not caught by the C++ code, but terminates the program catastrophically, with exit code 127. When the Haskell executable is compiled by ghc-7.2.3 or before, the bug does not happen. If, instead of having the main function in Haskell, we write a wrapper main function in C++, that calls the Haskell from a DLL (and the Haskell then calls back into C++), the bug does not happen. Hence, we surmise there is some ghc RTS initialisation that is specific to Windows, that deals with exception handling, and that is incorrect for certain versions of Windows. Attached to the ticket, please find (a) a C++ module, which exports a single function that throws an exception and catches it; (b) a Haskell module which imports the C++ via the FFI, and calls it; (c) a build script which compiles the C++ to a DLL, using the MSVC compiler, compiles the Haskell with ghc, and links them together. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10435> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10736: threadWaitRead/registerFd unusable
by GHC 03 Nov '15

03 Nov '15

#10736: threadWaitRead/registerFd unusable -------------------------------------+------------------------------------- Reporter: mboes | 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: | -------------------------------------+------------------------------------- The following program: {{{ module Main where import System.Posix.IO import GHC.Event main = do Just mgr <- getSystemEventManager fd <- openFd "/tmp/bleh" ReadOnly Nothing defaultFileFlags { nonBlock = True } key <- registerFd mgr (\_ _ -> putStrLn "hello") fd evtRead MultiShot return () }}} fails with: {{{ *** Exception: modifyFdOnce: permission denied (Operation not permitted) }}} Since `threadWaitRead` and family are implemented in terms of `registerFd`, they also fail with the same error. Perhaps I am misunderstanding how to use this function, but in this case the conditions that must hold true regarding file descriptors should be documented somewhere. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10848: GHC/GHCi should optionally print errors in reversed order
by GHC 03 Nov '15

03 Nov '15

#10848: GHC/GHCi should optionally print errors in reversed order -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: GHCi | Version: 7.11 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This would be super useful especially when refactoring. The way I usually do refactoring is that I break things with a change, and then reload GHCi, fixing a couple of errors at a time. I almost always start with first error, which means I have to scroll every time I reaload GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11020: Make worker-wrapper transformation optional.
by GHC 03 Nov '15

03 Nov '15

#11020: Make worker-wrapper transformation optional. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- I would like the worker-wrapper transformation to be optional, so I can disable it in my very specific use case. I propose to add a {{{-fworker- wrapper}}} flag, which enables the worker-wrapper transformation, and is implied by {{{-O}}} The expected users of this flag, which includes myself, are GHC API users. In my Haskell-to-Hardware compiler [1], which uses the GHC API, I have seen no benifits of the worker-wrapper transformation. It does however induce longer compilation times. Further discussion can be seen here: https://mail.haskell.org/pipermail /ghc-devs/2015-October/010096.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11025: Per-database shadowing
by GHC 03 Nov '15

03 Nov '15

#11025: Per-database shadowing -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Package | Version: 7.11 system | 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: -------------------------------------+------------------------------------- In `5b0191f74ab05b187f81ea037623338a615b1619`, I eliminated shadowing, on the justification that we should never pick the same component ID (previously installed package ID) for two distinct packages unless the ABIs of the packages were the same, so we could just globally assume that component IDs are unique. However, I've recently come across some cases where we can't easily actually make this be the case. Here are a few of them: 1. GHC's build system assumes that the ghc package will always be a library name of the form HSghc-7.11.a (i.e. that its component ID is ghc-7.11). It's a bit nontrivial to change this assumption, because there are stage1 shenanigans which are rewriting the version number to one without the date. But obviously if you are bootstrapping GHC with itself, the component ID of the GHC you are building will conflict with the component ID of the host GHC. 2. A similar situation exist for bootstrapping packages. When compiling GHC, we want to pick fairly deterministic component IDs for it in order to avoid needless rebuilding. But then if you turn around and use one of these builds to bootstrap GHC, if you use the same deterministic scheme you will end up with conflicting component IDs. 3. More generally, if you are building a package which is already in the global database (and thus not easily removable), it is sometimes VERY CONVENIENT to be able to pick whatever component ID you want, even if it's in the global database. (1) and (2) are cases of this. So I think what we want to do is bring back shadowing, but have it operate on a PER-DATABASE basis. For example, if we have the following databases: {{{ pkg.conf.1 foo-0.1-XXX bar-0.2-YYY (depends on foo-0.1-XXX) pkg.conf.2 foo-0.1-XXX baz-0.3-ZZZ (depends on foo-0.1-XXX) }}} If we stack pkg.conf.2 on top of pkg.conf.1, we invalidate foo-0.1-XXX FROM pkg.conf.1 (which simply means any packages from pkg.conf.1 which refer to it.) It also occurs to me that we should also be recording the ABIs of packages we depend on, to ensure consistency. Consider: {{{ pkg.conf.1 foo-0.1-XXX (abi is AAA) pkg.conf.2 foo-0.1-XXX (abi is BBB) pkg.conf.3 bar-0.1-YYY (depends on foo-0.1-XXX) }}} Which is the correct database to use `pkg.conf.3` with? We have no way of telling today! Sure, `pkg.conf.3` is incomplete, but this is a supported mode of operation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11025> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11048: Kind Incompatibility in GHC 7.6.3
by GHC 02 Nov '15

02 Nov '15

#11048: Kind Incompatibility in GHC 7.6.3 ----------------------------------------+--------------------------------- Reporter: skatenerd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- In [https://github.com/skatenerd/vectorracing/commit/ddb950a3c89f7ba5aae84050d2… this commit] I have added a line with an intentionally missing dollar- sign. This should result in a mundane build failure, but instead, GHC produces this message: {{{ src/Main.hs:50:3: Couldn't match kind `* -> *' with `*' Expected type: Window -> Maybe Integer -> t0 Curses (Maybe Event) Actual type: Window -> Maybe Integer -> t0 Curses (Maybe Event) Kind incompatibility when matching types: Window :: * -> * Window :: * The function `lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11026: Bump `base` version to 4.9.0.0
by GHC 02 Nov '15

02 Nov '15

#11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: | Version: libraries/base | 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11026> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 02 Nov '15

02 Nov '15

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ghorn): * cc: gregmainland@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11035: Add implicit call-stacks to partial functions in base
by GHC 02 Nov '15

02 Nov '15

#11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From https://www.reddit.com/r/haskell/comments/3qpefo/a_very_unfortunate_error_m… {{{ ghci> minimumBy compare [] *** Exception: Prelude.foldr1: empty list CallStack: error, called at libraries/base/GHC/List.hs:999:3 in base-4.8.2.0:GHC.List }}} This is not a very useful call-stack. It tells us that error was called in GHC.List, and if we happen to have the source we can even see where it was called. https://github.com/ghc/ghc/blob/master/libraries/base/GHC/List.hs#L999 But that's '''still''' not very helpful because: 1. It points us to some generic `errorEmptyList` function. This function always diverges, so by our current rule it ought to get a CallStack constraint. Oops! 2. Even if we add the CallStack to `errorEmptyList`, the next culprit will (presumably) be `foldr1`, where the stack ends again. `foldr1` is partial, but it doesn't '''always''' diverge, so our current rule would say it shouldn't get a CallStack. This is quite unfortunate because the CallStack will point the finger at `foldr1`, but the error message itself '''already does that'''. So we haven't really gained anything by using the CallStack-aware `error` in base. What we really want to know is where `foldr1` was called, which just so happens to be `minimumBy` itself! Ben Gamari pinged me earlier today on IRC with a similar instance in GHC.Arr. ---- So, I think we should '''consider''' expanding the use of CallStacks in base by one level, to partial functions. By "partial" I specifically mean functions that directly call `error` or one of its wrappers (like `errorEmptyList`). That means that {{{#!haskell head [] = error "bad" head (x:xs) = x }}} would get a CallStack, but {{{#!haskell minimumBy cmp = foldr1 min' where min' x y = case cmp x y of GT -> y _ -> x }}} would '''not''', even though `minimumBy` is also partial in the traditional sense. I recall three arguments against broader use of CallStacks: 1. '''Performance concerns''': CallStacks exist at runtime in the form of an extra parameter to each CallStack-aware function. This is a valid concern and we should certainly do some benchmarking to see what the effects are. 2. '''Readability concerns''': Adding CallStacks will clutter otherwise simple type signatures, e.g. {{{#!haskell head :: [a] -> a head :: (?callStack :: CallStack) => [a] -> a }}} Also a valid concern, especially considering that base functions are the first novices will encounter. But I think we can mitigate this one in two steps. (1) The `:type` command in ghci already suppresses the CallStacks (because it happens to invoke the constraint solver), but `:info` shows them. I think this is fine as is. (2) If haddock shows CallStacks (I'm not sure if it does), we could patch haddock to render them differently. For example, instead of rendering the full type, just render {{{ head :: [a] -> a }}} with a badge that indicates that `head` is location-aware. That would reduce the cognitive overhead of the larger type signature, while retaining the important data. 3. '''Slippery slope''': Where do we draw the line? Why should `head` get a CallStack but not `minimumBy`? I don't have a good answer to this one yet, apart from a suspicion that my proposal will get us a closer to an 80/20 balance. I'm sure this would need to go through the Core Libraries Committee, but I'd also like feedback from fellow GHC devs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11035> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17