March 2013 - ghc-tickets

[GHC] #7744: Can't install conduit via cabal-install
by GHC 17 Jun '13

17 Jun '13

#7744: Can't install conduit via cabal-install -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- When I did {{{cabal install hoogle}}} it failed on one of the dependencies, called conduit. Here is the output: {{{ Downloading conduit-1.0.2... Configuring conduit-1.0.2... Building conduit-1.0.2... Preprocessing library conduit-1.0.2... [1 of 7] Compiling Data.Conduit.Internal ( Data/Conduit/Internal.hs, dist/build/Data/Conduit/Internal.o ) [2 of 7] Compiling Data.Conduit.Util ( Data/Conduit/Util.hs, dist/build/Data/Conduit/Util.o ) [3 of 7] Compiling Data.Conduit ( Data/Conduit.hs, dist/build/Data/Conduit.o ) [4 of 7] Compiling Data.Conduit.List ( Data/Conduit/List.hs, dist/build/Data/Conduit/List.o ) [5 of 7] Compiling Data.Conduit.Binary ( Data/Conduit/Binary.hs, dist/build/Data/Conduit/Binary.o ) ghc: internal error: evacuate: strange closure type 8 (GHC version 7.6.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install conduit-1.0.2 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 2

[GHC] #7718: ios patch no 8: adjustor pools
by GHC 09 Jun '13

09 Jun '13

#7718: ios patch no 8: adjustor pools ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Other | Architecture: arm Failure: None/Unknown | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- "Adjustor" is the term used for a C function pointer that allows C code to call back to Haskell. Normally these are generated at runtime. However, the iOS kernel doesn't allow self-modifying code. So, on iOS we use a pool of precompiled adjustors of a fixed size, and this patch is the implementation for that. It consists of three parts: 1. A POOLSIZE pragma, that is used like this: foreign import ccall safe "wrapper" {-# POOLSIZE 100 #-} mkDelegate :: IO () -> IO (FunPtr (IO ())) This patch makes this pragma work on all platforms, but it'll have no effect on platforms other than iOS. I am not sure what the procedure is for additions of pragmas. Do pragmas require {-# LANGUAGE xx #-} ? Anyway, please review whether the approach taken here is acceptable. 2. The Haskell code in the compiler to generate the stubs for the pooled adjustors. 3. The runtime system's implementation of pooled adjustors in C. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 24

[GHC] #7653: incorrect handling of StackOverflow exception in the event manager
by GHC 09 Jun '13

09 Jun '13

#7653: incorrect handling of StackOverflow exception in the event manager --------------------------+------------------------------------------------- Reporter: nus | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.7 | Keywords: Os: Linux | Architecture: Unknown/Multiple Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- Under high pressure of `registerTimeout`s the event manager thread's stack overflows. Testcases: Shachaf initially reported this testcase on #ghc, which is irreproducible locally: {{{ import Control.Monad; import Control.Concurrent main = replicateM_ 1000000 (forkIO (threadDelay 1)) }}} to be compiled and run as follows: {{{ $ ghc -O2 -threaded Main.hs && time ./Main +RTS -N }}} Limiting the stack to the minimum helped to reproduce this locally, both on x86 and x64: {{{ import Control.Monad import Control.Concurrent main = replicateM_ 502 (forkIO (threadDelay 1)) -- 504 on x64 }}} {{{ $ ghc -O2 -threaded -with-rtsopts="-N8 -K4" rplfrk.hs && ./rplfrk # -K8 on x64 }}} and this, though less deterministically: {{{ import Control.Monad import Control.Concurrent main = replicateM_ 340 ( forkIO (threadDelay 1)) }}} {{{ $ ghc -O2 -threaded -rtsopts repl2-x86.hs && ./repl2-x86 +RTS -N1 -K4 }}} Error messages look like: {{{ Stack space overflow: current size 4 bytes. Use `+RTS -Ksize -RTS' to increase it. repl2-x86: sendWakeup: invalid argument (Bad file descriptor) [...repeated...] repl2-x86: ioManagerDie: write: Bad file descriptor }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7653> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 11

[GHC] #7633: Checkable "minimal complete definitions"
by GHC 09 Jun '13

09 Jun '13

#7633: Checkable "minimal complete definitions" -----------------------------+---------------------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: 6028 -----------------------------+---------------------------------------------- #6028 suggested warning on cyclic unimplemented defaults. This doesn't work for the reasons mentioned there, among others (also e.g. [http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html /Control-Applicative.html#g:2 `Alternative`] has mutually recursive `some` and `many` methods, which shouldn't be warned about). Figuring out when to warn automatically seems hard. But Haskell already has an ad-hoc mechanism for specifying which methods need to be implemented: A "minimal complete definition" specified in the comments of almost every class definition that has optional methods. Unfortunately comments are aren't compiler-checked. It seems that the simplest solution would be to specify these in a way that the compiler can understand. The obvious approach is to add a pragma for it in the class definition. In particular, one could write a pragma for each "minimal set" of definitions, and the compiler could warn if none of them are implemented (and suggest which methods to implement). This lets us keep the convenience of default method implementations without losing safety. Without any pragmas, the compiler could fall back to the set "all methods without defaults", which is what it uses now. It might look something like this: {{{ class Functor m => Monad m where return :: a -> m a (>>=) :: m a -> (a -> m b) -> m b m >>= f = join (fmap f m) join :: m (m a) -> m a join m = m >>= id {-# MINIMAL return, join #-} {-# MINIMAL return, (>>=) #-} class Eq a where (==), (/=) :: a -> a -> Bool x == y = not (x /= y) x /= y = not (x == y) {-# MINIMAL (==) #-} {-# MINIMAL (/=) #-} }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 12

[GHC] #7738: Testsuite failures for ghci tests normalising stderr output for .exe
by GHC 08 Jun '13

08 Jun '13

#7738: Testsuite failures for ghci tests normalising stderr output for .exe -------------------------+-------------------------------------------------- Reporter: rassilon | Owner: Type: bug | Status: new Priority: normal | Component: Test Suite Version: | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- On GHC-Head: Tests getDirContents002 and process004 both specify normalise_exe in their options, but these both only generate expected error results on stderr. Here's an example of what happens currently: {{{ --- ./getDirContents002.stderr-mingw32 2013-02-09 21:09:27 -0500 +++ ./getDirContents002.run.stderr 2013-03-04 17:29:34 -0500 @@ -1 +1 @@ -getDirContents002.exe: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.) +getDirContents002: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.) *** unexpected failure for getDirContents002(ghci) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7738> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 4

[GHC] #7739: Testsuite failures for HPC way tests on Windows
by GHC 08 Jun '13

08 Jun '13

#7739: Testsuite failures for HPC way tests on Windows -------------------------+-------------------------------------------------- Reporter: rassilon | Owner: Type: bug | Status: new Priority: normal | Component: Test Suite Version: | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- Here's what happens on GHC-HEAD: {{{ =====> annrun01(hpc) 15 of 3566 [0, 0, 6] cd ./annotations/should_run && $MAKE -s --no-print-directory config Creating Config.hs ... cd ./annotations/should_run && 'd:/Dev/ghc/ghc/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history --make -o annrun01 annrun01 -O -fhpc -hpcdir .hpc.annrun01 -package ghc >annrun01.comp.stderr 2>&1 cd ./annotations/should_run && ./annrun01 </dev/null >annrun01.run.stdout 2>annrun01.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: in module 'Config' Hpc failure: module mismatch with .tix/.mix file hash number (perhaps remove annrun01.exe.tix file?) *** unexpected failure for annrun01(hpc) }}} The cause appears to be due to not cleaning up .exe.tix files. After deleting the files the tests pass again. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 3

[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] #7715: threadDelay causes segfault on Mac if compiled by 32bit GHC
by GHC 01 Jun '13

01 Jun '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

[GHC] #7729: GHC panics. Invalid core
by GHC 27 May '13

27 May '13

#7729: GHC panics. Invalid core -----------------------------+---------------------------------------------- Reporter: Khudyakov | 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: -----------------------------+---------------------------------------------- Following code snippet triggers panic: {{{ {-# LANGUAGE FlexibleContexts, TypeFamilies #-} module Monad where class Monad m => PrimMonad m where type PrimState m class MonadTrans t where lift :: Monad m => m a -> t m a class (PrimMonad (BasePrimMonad m), Monad m) => MonadPrim m where type BasePrimMonad m :: * -> * liftPrim :: BasePrimMonad m a -> m a newtype Rand m a = Rand { runRand :: Maybe (m ()) -> m a } instance (Monad m) => Monad (Rand m) where return = Rand . const . return (Rand rnd) >>= f = Rand $ \g -> (\x -> runRand (f x) g) =<< rnd g instance MonadTrans Rand where lift = Rand . const instance MonadPrim m => MonadPrim (Rand m) where type BasePrimMonad (Rand m) = BasePrimMonad m liftPrim = liftPrim . lift }}} GHC 7.6.2 panics {{{ $ ghc-7.6.2 -c Monad.hs ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-unknown-linux): cgLookupPanic (probably invalid Core; try -dcore-lint) $dMonadTrans{v ahe} [lid] static binds for: local binds for: main:Monad.lift{v ra} [gid[ClassOp]] main:Monad.liftPrim{v rc} [gid[ClassOp]] main:Monad.$p1PrimMonad{v rgv} [gid[ClassOp]] main:Monad.$p1MonadPrim{v rgA} [gid[ClassOp]] main:Monad.$p2MonadPrim{v rgB} [gid[ClassOp]] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} whereas 7.4.2 reports type error {{{ $ ghc-7.4.2 -c Monad.hs Monad.hs:28:14: Occurs check: cannot construct the infinite type: m0 = t0 m0 Expected type: BasePrimMonad (Rand m) a -> Rand m a Actual type: m0 a -> Rand m a In the expression: liftPrim . lift In an equation for `liftPrim': liftPrim = liftPrim . lift }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7729> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6