July 2013 - ghc-tickets

[GHC] #8035: STM transaction left open if there is an orElse on the path between throwSTM and catchSTM
by GHC 07 Jul '13

07 Jul '13

#8035: STM transaction left open if there is an orElse on the path between throwSTM and catchSTM -----------------------------+---------------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: stm rts Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ main = join $ atomically $ do catchSTM (throwSTM ThreadKilled `orElse` return (putStrLn "wtf")) (\(e::SomeException) -> return (putStrLn "ok")) }}} This program crashes with a segmentation fault. Tested with GHC HEAD. I attach the testcase and my proposed fix for the issue. I've run the fast testsuite with the proposed fix without new defects. On the other hand I'm very new to GHC, so while I'm sure in the defect and the test, the fix may be bogus. Thanks goes to Mihály Bárász for discovering the issue. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8035> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 07 Jul '13

07 Jul '13

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by igloo): And also with a validated HEAD (with dynamic ghci). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 07 Jul '13

07 Jul '13

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+---------------------------------- Reporter: Doug310 | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by igloo): I can reproduce it with `ghc-7.6.2-x86_64-apple-darwin.tar.bz2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7936: newStdGen leaks memory when result is not used
by GHC 07 Jul '13

07 Jul '13

#7936: newStdGen leaks memory when result is not used -------------------------------------+------------------------------------ Reporter: ryantrinkle | Owner: rrnewton Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/random | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by igloo): * owner: => rrnewton * difficulty: => Unknown * milestone: => 7.8.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7936#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7926: eventfd: unsupported operation when doing anything
by GHC 07 Jul '13

07 Jul '13

#7926: eventfd: unsupported operation when doing anything ----------------------------------+---------------------------------- Reporter: guest | Owner: AndreasVoellmy Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by guest): My program that was running into this bug was built with -threaded. Building it without the threaded runtime seems to bypass the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7926#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8029: batch-mode recompilation checking sometimes fails
by GHC 07 Jul '13

07 Jul '13

#8029: batch-mode recompilation checking sometimes fails -----------------------------+--------------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: recompilation, batch-mode Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | -----------------------------+--------------------------------------------- Comment (by igloo): Note that sometimes the source file legitimately won't exist. For example, if the real source file is `Foo.hsc`, then you might have a `Foo.hi` with no `Foo.hs` (it may have been removed, or it may have been put in some other temporary directory). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8029#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 07 Jul '13

07 Jul '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by a.ulrich): * cc: alex@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8042: `:load *` and `:add *` misbehave in presence of `-fobject-code`
by GHC 07 Jul '13

07 Jul '13

#8042: `:load *` and `:add *` misbehave in presence of `-fobject-code` ------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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 documentation states for the `*`-forms of `:add` and `:load` that > Normally pre-compiled code for a module will be loaded if available, or otherwise the module will be compiled to byte-code. Using the `*` prefix forces a module to be loaded as byte-code. However, this seems to be ignored when `-fobject-code` has been enabled. In that case, the compiled code is ''always'' used, regardless of whether the `*`-form is used. Having `-fobject-code` enabled is very useful for large projects as it cuts down loading times, whereas being able to use the `*`-forms on individual modules from the target set allows for being inside the module context, which is very useful for integration with Emacs (and IDEs), or for being able to set breakpoints. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7926: eventfd: unsupported operation when doing anything
by GHC 06 Jul '13

06 Jul '13

#7926: eventfd: unsupported operation when doing anything ----------------------------------+---------------------------------- Reporter: guest | Owner: AndreasVoellmy Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by guest): At least the eventfd part of this seems to be a bug in glibc, when used with an older linux kernel version, such as 2.6.32. See this bug report I've filed on that: <http://bugs.debian.org/715212> I am unsure if the pattern match failure is being caused by the eventfd failure, or is unrelated. I have seen a program only show the pattern match failure, while a different program first prints the eventfd error message before failing due to the pattern match failure. -- Joey Hess -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7926#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8041: Extraction of Uniques is in some places done inefficiently
by GHC 06 Jul '13

06 Jul '13

#8041: Extraction of Uniques is in some places done inefficiently ------------------------------------+------------------------------------- Reporter: parcs | 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: | ------------------------------------+------------------------------------- In some places in the GHC sources, extraction of a `Unique` from a `UniqSupply` is done in the following manner: {{{ case splitUniqSupply us of (us1,us2) -> (uniqFromSupply us1, us2) }}} This way of splitting a `UniqSupply` into a `Unique` and a new `UniqueSupply` is needlessly inefficient since it forces and then throws away an extra `Unique`. `takeUniqFromSupply` should be used instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8041> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3