May 2013 - ghc-tickets

[GHC] #7636: threadStackUnderflow: not enough space for return values
by GHC 06 Jun '13

06 Jun '13

#7636: threadStackUnderflow: not enough space for return values -------------------------+-------------------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- While filling a {{{Control.Concurrent.STM.TBQueue}}} (stm-2.4) with values the system crashes with the following message: {{{ internal error: threadStackUnderflow: not enough space for return values (GHC version 7.4.2 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7636> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 15

[GHC] #7702: Memory Leak in CoreM (CoreWriter)
by GHC 06 Jun '13

06 Jun '13

#7702: Memory Leak in CoreM (CoreWriter) -----------------------------------------+---------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time performance bug | Blockedby: Blocking: | Related: -----------------------------------------+---------------------------------- While running HERMIT on extended examples, we noticed that the CoreWriter component of CoreM is building up unevaluated SimplCount expressions. Attached is a one line patch to make the field in the CoreWriter record strict, which fixes the leak. Also attached are heap profiles before and after to verify the fix. (You'll notice we have other memory leaks in HERMIT to address, the important bit being the big CoreWriter peak is gone in after.pdf.) These were generated by running a large number of HERMIT transformations in a batch, with HERMIT calling ghc with +RTS -hT -RTS. I'm not sure how this affects compilation time or allocation when SimplCount is not the VerySimplCount constructor. Would the nofib suite answer these questions? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7702> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 17

[GHC] #7859: runghc should give an error when the path to ghc is invalid
by GHC 04 Jun '13

04 Jun '13

#7859: runghc should give an error when the path to ghc is invalid ----------------------------------------------+----------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: None Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- runghc has a -f option which allows to specify the path to GHC. However, it uses `rawSystem` and if the path is incorrect, we only get a nonzero exit code. For example, attempting to use "ghc -fdefer-type-errors X.hs" gives absolutely no output. Attached patch uses `findExecutable` and gives an error message if the executable is not found. This is not the ideal solution, but I think it's better than the current state. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7859> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 5

[GHC] #7931: Deriving Read of an empty datatype crashes
by GHC 02 Jun '13

02 Jun '13

#7931: Deriving Read of an empty datatype crashes -----------------------------+---------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Standalone deriving Read of an empty datatype crashes: {{{ {-# LANGUAGE StandaloneDeriving #-} data A deriving instance Read A }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130515 for x86_64-unknown-linux): Prelude.foldr1: empty list Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} (Oddly, the "panic" message is given only by ghc, not ghci, but this is minor.) While the Read instance seems to be of little use, it can be used for reading types such as `Either Void Int`. Patch attached. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7931> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 4

Re: [GHC] #7953: Segfault on x86 with -O2
by GHC 31 May '13

31 May '13

#7953: Segfault on x86 with -O2 -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: x86 | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | -------------------------+-------------------------------------------------- Comment(by kazu-yamamoto): Note that this is not limited to MacOS. This can be reproduced on 32bit Linux, too. This segfault is caused by "prio e > pt". This happens if Prio is either Float or Double. Int does not cause this segfault. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7953#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7715: threadDelay causes segfault on Mac if compiled by 32bit GHC
by GHC 31 May '13

31 May '13

#7715: threadDelay causes segfault on Mac if compiled by 32bit GHC -----------------------------+---------------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following code causes segfault {{{ main :: IO () main = do replicateM_ 100 $ forkIO $ do threadDelay 1000000 putStrLn "Hello, world!" threadDelay 5000000 }}} if compiled with 32bit GHC head on Mac. 64bit GHC head does not cause this problem. 32bit GHC 7.4.2 does not, either. I don't see this bug both on FreeBSD and Linux. "gdb" caught the following on each run: {{{ Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000005 [Switching to process 51076 thread 0x20b] 0x00000005 in ?? () }}} {{{ Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000019 [Switching to process 50933 thread 0x20b] 0x00000019 in ?? () }}} {{{ Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x40e40348 [Switching to process 51004 thread 0x20b] 0x00f28aa5 in base_GHCziEventziPSQ_atMostzuzdszdwatMosts_info () }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7715> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 16

Re: [GHC] #5687: Friendly Interface for auto-completion of GHCi
by GHC 31 May '13

31 May '13

#5687: Friendly Interface for auto-completion of GHCi ---------------------------------+------------------------------------------ Reporter: linsumang | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 7.2.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => patch -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5687#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7943: Malformed record leads to panic
by GHC 27 May '13

27 May '13

#7943: Malformed record leads to panic -------------------------------+-------------------------------------------- Reporter: scvalex | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- The following code makes GHC panic (note the extra String after B): {{{ data Foo = A { bar :: String } | B String { bar :: String } }}} {{{ % runhaskell Bug.hs ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tc_hs_type: record Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7943> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 27 May '13

27 May '13

#6135: Unboxed Booleans -------------------------------+-------------------------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #605 -------------------------------+-------------------------------------------- Comment(by jstolarek): Simon M., you're right - there are no changes in the code generator. According to tests and my analysis of generated assembly everything works correct. I wish I could give an explanation of how that works in the codegen but I have to admit that I am not familiar with that part of the compiler. I'll take a look at the code and see if I can give a more professional response :) Right now I'm trying to see if I can use new primops to get more performance out of Gregory Collins' hashtables package - I'll post here if I get good results. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:58> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7930: Nested STM Invariants are lost
by GHC 27 May '13

27 May '13

#7930: Nested STM Invariants are lost ----------------------------------------+----------------------------------- Reporter: fryguybob | Owner: fryguybob Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.3 | Keywords: STM Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- Invariants from a successful nested transaction should be merged with the parent. {{{ import Control.Concurrent import Control.Concurrent.STM main = do x <- atomically $ do a <- newTVar True (always (readTVar a) >> retry) `orElse` return () return a atomically (writeTVar x False) -- Should not and does not fail y <- atomically $ do a <- newTVar True always (readTVar a) `orElse` return () return a atomically (writeTVar y False) -- Should fail, but does not! putStrLn "Ahhh!" z <- atomically $ do a <- newTVar True always (readTVar a) return a atomically (writeTVar z False) -- should and does fail }}} I know how to fix this. I'll have a patch with some tests and a fix soon. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7930> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3