May 2014 - ghc-tickets

[GHC] #9021: rts/linker.c has a memory leak in the dlopen/dlerror code
by GHC 03 Jun '14

03 Jun '14

#9021: rts/linker.c has a memory leak in the dlopen/dlerror code -------------------------------------+------------------------------------- Reporter: hgolden | Owner: hgolden Type: bug | Status: new Priority: low | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Keywords: linker, memory | Operating System: POSIX leak | Type of failure: Runtime Architecture: Unknown/Multiple | performance bug Difficulty: Moderate (less | Test Case: than a day) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- The Coverity Scan of ghc highlighted a memory leak (CID 43168) in the internal_dlopen function in rts/linker.c. I wrote this code originally and I recall that there was a memory leak in certain situations, but I didn't fix it at the time because it seemed to be rather minor and only would occur in unusual cases. However, since Coverity identified it, I have thought about it and know how to fix the leak, so I am creating this ticket. The leak occurs because the error message from dlerror must be copied to allocated memory, since the dlerror message is not guaranteed to be stable, and its code is not guaranteed to be reentrant (see POSIX dlopen/dlerror documentation). As I originally coded Trac ticket #2615, I didn't bother to free the allocated memory. The fix is to make sure that the allocated memory is freed once the error message is displayed. Memory is only allocated if there is an error, so it must be freed only when an error has been identified and processed. As far as I know, this bug only exists on a POSIX system. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9021> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9068: Don't uninstall signal handlers if none were installed
by GHC 03 Jun '14

03 Jun '14

#9068: Don't uninstall signal handlers if none were installed --------------------------+------------------------------------------------ Reporter: tomgr | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 Runtime System | Operating System: Windows Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ GHC 7.8.2 calls resetSignalHandlers even when --install-signal-handlers=no is specified. On windows this results in the call to SetConsoleCtrlHandler failing. The attached patch only calls resetSignalHandlers when there are signal handlers to remove (it mirrors the logic used when installing the handlers). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9068> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9148: tryReadMVar locks up the process with +RTS -N2 or greater
by GHC 03 Jun '14

03 Jun '14

#9148: tryReadMVar locks up the process with +RTS -N2 or greater ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The new `tryReadMVar` is missing an `unlockClosure` call, which causes the whole process to hang when used with +RTS -N2 or greater. I'll push the fix shortly. We should treat this as a blocker for 7.8.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9148> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5599: msys has bad Unicode support
by GHC 31 May '14

31 May '14

#5599: msys has bad Unicode support -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.4.1 Resolution: fixed | Version: 7.2.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: llibraries/tests/IO/T3307, | Unknown/Multiple environment001 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by awson): Replying to [comment:6 schyler]: > #8842 would be a good thing to check before making it default. You shall *never* install msys2 runtime and development tools. You should only install msys2-base distribution and mingw(32|64)-* runtime and development tools. You also shall start msys2 shell with mingw(32|64)_shell.bat script included into distribution. This way you receive (native 32 or 64 bit windows) mingw-w64 runtime based development environment with no remnants of Msys2 runtime. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5599#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5599: msys has bad Unicode support
by GHC 31 May '14

31 May '14

#5599: msys has bad Unicode support -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: Priority: normal | closed Component: Compiler | Milestone: 7.4.1 Resolution: fixed | Version: 7.2.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Test Case: llibraries/tests/IO/T3307, | Unknown/Multiple environment001 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by schyler): Replying to [comment:5 simonpj]: > MSYS2 is way better than MSYS, so I think we should just adopt it. I'm making it an expected pass. > > Simon #8842 would be a good thing to check before making it default. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5599#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1388: Newbie help features
by GHC 31 May '14

31 May '14

#1388: Newbie help features -------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature | Status: new request | Milestone: ⊥ Priority: low | Version: 6.6.1 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Changes (by nomeata): * cc: hvr (added) * failure: => None/Unknown Comment: `type Bar = (Char, Int)` works now in GHCi. `f = 1` doesn’t, but given that GHCi supports all(?) other toplevel declarations by now, I wonder why. I could even print something helpful like {{{ > f = 1 Defined: f :: Num a => a }}} or less verbose {{{ > f = 1 f :: Num a => a }}} so that the user knows what’s going on. Or simply treat it exactly like `let f = 1`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1388#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7241: GHC-7.6.1 panics on template haskell code
by GHC 31 May '14

31 May '14

#7241: GHC-7.6.1 panics on template haskell code ---------------------------------------+----------------------------------- Reporter: akamaus | Owner: Yuras Type: bug | Status: patch Priority: normal | Milestone: 7.8.3 Component: Template Haskell | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by Amatic): * cc: lightwing15@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7241#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9075: Per-thread weak pointer list (remove global lock on mkWeak#)
by GHC 30 May '14

30 May '14

#9075: Per-thread weak pointer list (remove global lock on mkWeak#) ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Operating System: Unknown/Multiple Keywords: easy | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Currently, we have to take out the storage manager lock when a weak pointer is allocated. If you're making a lot of weak pointers, this could become a bottleneck. We should maintain a per-thread weak pointer list per generation, so that we don't have to take out a lock. Marking priority as low since I don't think anyone actually is trying to allocate tons of weak pointers on multiple threads, but I think this optimization should be relatively cheap. Probably a good starter ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7521: Simplifier ticks exhausted when compiling Accelerate example.
by GHC 30 May '14

30 May '14

#7521: Simplifier ticks exhausted when compiling Accelerate example. ---------------------------------------+----------------------------------- Reporter: eamsden | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Changes (by George): * cc: george.colpitts@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7521#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7521: Simplifier ticks exhausted when compiling Accelerate example.
by GHC 30 May '14

30 May '14

#7521: Simplifier ticks exhausted when compiling Accelerate example. ---------------------------------------+----------------------------------- Reporter: eamsden | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time crash | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by George): Does this fail on 7.8.2? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7521#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0