February 2014 - ghc-tickets

[GHC] #8512: Add flag like '-xc' that only reports uncaught exceptions
by GHC 21 Feb '14

21 Feb '14

#8512: Add flag like '-xc' that only reports uncaught exceptions ------------------------------------+------------------------------------- Reporter: blitzcode | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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: | ------------------------------------+------------------------------------- The -xc RTS flag reports the stack trace of all exceptions. This can be very noisy when, for instance, certain http or parsing libraries are used that throw many exceptions, often handled fully internal, during their normal operation. Having multiple threads makes it even noisier. I'd think having a flag like -xc that only reports uncaught exceptions would be useful. It seems the GHCi debugger has a flag to only stop on uncaught exceptions, maybe this could be made available as an RTS option? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8512> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8804: BlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible from another thread
by GHC 21 Feb '14

21 Feb '14

#8804: BlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible from another thread --------------------------+------------------------------------------------ Reporter: bholst | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Runtime System | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ GHC's runtime system throws a BlockedIndefinatelyOnMVar exception when the thread blocking an the MVar is the only one having a direct access to it. It assumes that there will be nothing written into the MVar in the future. This would be the correct behaviour if there were no weak references. The runtime system even throws the Exception when another thread still has a weak reference to the MVar. Consider the following example: {{{ import Control.Concurrent import System.Mem.Weak import Data.Maybe import Control.Monad main = do m <- newEmptyMVar w <- mkWeakMVar m (return ()) forkIO $ do threadDelay 1000000 n <- deRefWeak w when (isJust n) $ putMVar (fromJust n) () takeMVar m }}} At the time of ''takeMVar'' the forked thread has a weak reference to the MVar and it will put a value in it. However, the runtime system throws the Exception: {{{ % ghc BlockingOnMVar.hs -threaded Linking BlockingOnMVar ... % ./BlockingOnMVar +RTS -N2 BlockingOnMVar: thread blocked indefinitely in an MVar operation }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8804> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #3693: Show stack traces
by GHC 20 Feb '14

20 Feb '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): I would really, really like a wiki page that explains all this. Reverse- engineering it from a 65-comment trail is very labour intensive. The wiki page can by all means point to the paper (preferably not behind a paywall), explain the principles, etc. That might not take many words -- if so, that's great! Meanwhile I will go back to the paper Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:66> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3693: Show stack traces
by GHC 20 Feb '14

20 Feb '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by scpmw): > given a proposed Core-Core transformation, does the transformation meet the specfification or not? Simon covered the basic idea pretty well. From the transformation point of view, the general rule of thumb is that source notes want to stay on covered code (even if transformed), but don't care too much about new code getting added in ("soft scope"). So we can for example work with fusion by simply floating "upwards": {{{ src<1.hs> foldr k z (src<2.hs> build g) ===> src<1.hs> src<2.hs> g k z }}} Cost-centres would disallow this kind of transformation, as the new stacks have little to do with the old one. Source notes on the other hand want the transformation to still happen, so we just annotate the new expression with everything that appeared on the deconstructed source expression. The paper goes into (way) more detail here, but the short version is that while not always optimal, this approach is always legal. The only special case so far is `let`- and `case`-floating, where we run into the same problems as cost-centres (and use pretty much the same solution). Additionally we decide to not care too much about allocation costs at a number of points where it would have made things too messy. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:65> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3693: Show stack traces
by GHC 20 Feb '14

20 Feb '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): Yes, it would maybe be less confusing if there was a separate ticket for Peter's initial patches. The ticket could be named "Implement an object code to source code mapping" or maybe just "Emit DWARF in NCG". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:64> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8786: libraries/primitive build failure on Solaris 10
by GHC 20 Feb '14

20 Feb '14

#8786: libraries/primitive build failure on Solaris 10 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries (other) | Version: 7.8.1-rc1 Keywords: | Operating System: Solaris Architecture: x86_64 (amd64) | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Solaris 10 is distributed with GNU C 3.4.3 compiler. This compiler does not support -ftree-vectorize command-line option and so its cc1 process fails on it which also mean that ghc-cabal fails compiling primitive package. The solution is simple to remove the -ftree-vectorize for solaris although it'll penalize Solaris 11 which is distributed with GNU C 4.6.2. I've solved that and provided a patch to primitive project in a pull request here: https://github.com/haskell/primitive/pull/6 I've entered the bug here to also track it and lobby for this issue to be solved for 7.8.1 release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8786> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8754: :set +s always says space usage is 0 bytes
by GHC 20 Feb '14

20 Feb '14

#8754: :set +s always says space usage is 0 bytes ------------------------------------+--------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- :set +s always says space usage is 0 bytes {{{ ghci GHCi, version 7.8.20140130:... ... sumOfPrimes2 40000000 25 1677366278943 it :: Int (14.84 secs, 0 bytes) }}} setting to high as this is a regression -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8760: ghc 7.8: ghc-split not installed
by GHC 20 Feb '14

20 Feb '14

#8760: ghc 7.8: ghc-split not installed --------------------------------+------------------------------------------ Reporter: | Owner: MagnusTherning | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1-rc1 Component: Build System | Operating System: Linux Keywords: | Type of failure: Installing GHC failed Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ These are the steps I run to build and install (to prepare for packaging): {{{ ./sync-all -r git://git.haskell.org get -b ghc-7.8 ./boot ./configure --prefix=/usr make -j 5 make DESTDIR=/path/to/prepackage/dir install }}} The build itself works fine, the installed binaries work for simple tests like compiling ''hello, world'', starting {{{ghci}}}, etc. However, building '''mtl''' failed with {{{ Configuring mtl-2.1.2... Building mtl-2.1.2... Preprocessing library mtl-2.1.2... [ 1 of 21] Compiling Control.Monad.Writer.Class ( Control/Monad/Write/Class.hs, dist/build/Control/Monad/Writer/Class.o ) ghc: could not execute: /usr/lib/ghc-7.8.0.20140204/ghc-split }}} So it seems ''ghc-split'' isn't installed by {{{make install}}}. It also isn't included in the output of {{{make binary-dist}}}. I've seen this on both ''x86'' and ''x86_64''. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #3693: Show stack traces
by GHC 20 Feb '14

20 Feb '14

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonmar): Simon - the best place to start is Peter and David's paper from last year's Haskell Symposium: http://dl.acm.org/citation.cfm?id=2503788 I think the next level of detail is the comments in the code. If you point to places where more explanation is needed, I'm sure Peter will be happy to add it. This is orthogonal to other methods for stack tracing, including the existing cost-centre-stack profiling. What these patches do is establish a best-effort mapping from object code to source code, ''without affecting what code gets generated at all''. It should have zero effect on optimisation - that's the main point. Then we can use the information later to try to make sense of the stack, and for profiling. There are follow-on patches to add support for these. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:63> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8802: createProcess implictlitly escapes and quotes command line parameters
by GHC 20 Feb '14

20 Feb '14

#8802: createProcess implictlitly escapes and quotes command line parameters -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: libraries/process | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I've just run into severe usability issue with the `process` library. It turns out that it performs quoting and escaping of command line parameters. The result is that it is impossible to run many shell commands that contain "unsafe" characters: {{{ diff <(echo $ENV_FOO) <(echo $ENV_BAR) awk 'NR<=10' Foo.txt }}} because they are turned into some nonsense. The culprit is `translate` function in libraries/process/System/Process/Internal.hs. I'm not fixing this myself as I assume there was some motivation behind escaping and quoting. I'm assigning high priority as it makes impossible to create shell processes correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8802> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8