April 2013 - ghc-tickets

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

05 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] #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

[GHC] #7866: floor (0/0) :: Int is different with -O0 and -O1
by GHC 24 May '13

24 May '13

#7866: floor (0/0) :: Int is different with -O0 and -O1 ----------------------------------------+----------------------------------- Reporter: alang9 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- This program: {{{ main = print (floor (0/0) :: Int) }}} prints a different result with -O0: {{{ 0 }}} and -O1: {{{ -9223372036854775808 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7866> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7799: Assembly error while building GHC 7.7
by GHC 20 May '13

20 May '13

#7799: Assembly error while building GHC 7.7 --------------------------------+------------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: x86 Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- While building GHC 7.7 (after running `make') I got this error message: {{{ $ "inplace/bin/ghc-stage1" -keep-tmp-files -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base /dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist- install/build/autogen -Ilibraries/base/include -optP- DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist- install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fasm -no-user-package-db -rtsopts -odir libraries/base/dist- install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./System/Posix/Internals.hs -o libraries/base/dist- install/build/System/Posix/Internals.dyn_o <braries/base/dist-install/build/System/Posix/Internals.dyn_o ghc23405_0.c: Assembler messages: ghc23405_0.c:127:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:153:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:181:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:207:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:235:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:261:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:285:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:311:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:339:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:367:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:393:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:421:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:449:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:477:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:505:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:525:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:526:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:527:0: Error: Missing symbol name in directive ghc23405_0.c:527:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:528:0: Error: Missing symbol name in directive [1] baldur@baldur-lappi:~/ghc> "inplace/bin/ghc-stage1" -keep-tmp-files -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H64m -O0 -fasm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist- install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base /dist-install/build/autogen -Ilibraries/base/include -optP- DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist- install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-gmp-0.5.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fasm -no-user-package-db -rtsopts -odir libraries/base/dist- install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./System/Posix/Internals.hs -o libraries/base/dist- install/build/System/Posix/Internals.dyn_o <braries/base/dist-install/build/System/Posix/Internals.dyn_o ghc23405_0.c: Assembler messages: ghc23405_0.c:127:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:153:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:181:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:207:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:235:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:261:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:285:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:311:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:339:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:367:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:393:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:421:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:449:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:477:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:505:0: Error: junk `.get_pc_thunk.bx' after expression ghc23405_0.c:525:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:526:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:527:0: Error: Missing symbol name in directive ghc23405_0.c:527:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:528:0: Error: Missing symbol name in directive ghc23405_0.c:528:0: Error: junk at end of line, first unrecognized character is `.' ghc23405_0.c:529:0: Error: junk at end of line, first unrecognized character is `1' ghc23405_0.c:528:0: Error: junk at end of line, first unrecognized character is `.' ghc23405_0.c:529:0: Error: junk at end of line, first unrecognized character is `1' }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7799> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #7592: Building the latest master branch on FreeBSD 9.1 fails
by GHC 20 May '13

20 May '13

#7592: Building the latest master branch on FreeBSD 9.1 fails -----------------------------+---------------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following sequence fails on FreeBSD 9.1: {{{ % perl boot % ./configure --prefix=/ghc-head --with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp- includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with- gcc=/usr/local/bin/gcc47 --with-gcc-4.2=/usr/local/bin/gcc47 % gmake -j10 -d MAKE=gmake ... Putting child 0x801e5fd80 (ghc/stage1/package-data.mk) PID 36063 on the chain. Recipe of `ghc/stage1/package-data.mk' is being run. Pruning file `compiler/stage1/package-data.mk'. Live child 0x801e5fd80 (ghc/stage1/package-data.mk) PID 36063 Configuring ghc-bin-7.7.20130111... Warning: 'data-dir: ..' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. Reaping winning child 0x801e5fd80 PID 36063 Removing child 0x801e5fd80 PID 36063 from chain. Considering target file `ghc/stage1/package-data.mk'. File `ghc/stage1/package-data.mk' was considered already. Re-executing[2]: gmake -r --no-print-directory -f ghc.mk phase=0 phase_0_builds GNU Make 3.82 Built for amd64-portbld-freebsd9.1 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Reading makefiles... Reading makefile `ghc.mk'... ghc.mk:84: *** Make has restarted itself 2 times; is there a makefile bug?. Sto p. Reaping losing child 0x80156e290 PID 34605 gmake: *** [all] Error 2 Removing child 0x80156e290 PID 34605 from chain. }}} If I type "gmake -j10 MAKE=gmake" gain, the building completes. I believe this is relating to http://www.haskell.org/pipermail/glasgow- haskell-users/2012-March/022150.html Actually if I remove "error" on line 84, this does not happen and the building completes without any problems. GHC for bootstrapping: 7.4.1, GCC 4.7.3, gmake: 3.82 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7592> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #7834: dyn way and INTEGER_LIBRARY=integer-simple
by GHC 20 May '13

20 May '13

#7834: dyn way and INTEGER_LIBRARY=integer-simple -----------------------------+---------------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- a standard bootstrap with {{{ perl boot ./configure make INTEGER_LIBRARY=integer-simple }}} causes some problems: 1. there is a panic (at least when `-j4`) "fromJust..." (which strangely disappears on the second attempt) 2. `__word_encode{Float|Double}` is not found by the linker. There are `__int_encode{Float|Double}` symbols available, though, and changing the source helps for linking, but not for correctness, obviously. I'll add specific details (if not trivially reproducible) as soon as I am back at my dev machine. The bottom line is that since GHC HEAD now builds the 'dyn' way by default, this kind of bootstrap always fails. Normally not a problem on desktop linux, but in combination with a gmp-less embedded linux and cross-compiling it becomes annoying. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7834> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7831: Bad fragmentation when allocating many large objects
by GHC 13 May '13

13 May '13

#7831: Bad fragmentation when allocating many large objects -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Consider our good old friend, the space-leaky list program: {{{ import Control.Exception import System.Environment f n = let xs = [1..n] in sum xs * product xs main = do [n] <- getArgs evaluate (f (read n :: Integer)) }}} It is not surprising that this program is quite the memory guzzler; what is surprising is how much GHC *wastes* when evaluating this program: {{{ Fragmentation, wanted 95 blocks, 105 MB free }}} (For reference, a block is 4k, so 95 blocks is a measly 380k!) The magnitude of the problem can be seen in this graphic: [[Image(http://web.mit.edu/~ezyang/Public/fragmentation-ghc.png)]] (The x-axis takes advantage of the fact that the number of requested blocks increases ~linearly over time, since we keep multiplying the integer which adds a constant number of extra bytes to the representation; unused free memory corresponds to blocks of free memory in GHC's free list, which it is holding onto from the OS but not using to store user data.) When the requested allocations are *just* large enough (just slightly over half a megablock, or 128 blocks), we start allocating a megablock per allocation and waste half of the megablock, since none of the leftovers are ever large enough to store any of the later allocations. Can we do anything about this? One possibility is to occasionally check how much space we're losing to fragmentation, and everyone once in a while pay the cost of copying tenured large objects and pack them together in a megablock group (obviously one wants to avoid doing this too often, since copying large objects is expensive!) I'm open to better suggestions though! (Apologies if this is a duplicate; I didn't see any open tickets with the word "fragmentation" in them). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7831> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7841: Stage1Only conditional program/package building
by GHC 12 May '13

12 May '13

#7841: Stage1Only conditional program/package building -----------------------------+---------------------------------------------- Reporter: elliottt | Owner: Type: feature request | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Stage1Only Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This patch includes changes to allow programs and packages to be disabled by stage when building GHC. == rule/build-package.mk == * Add guards for "disable-$(dir)-$(stage)" around the rule body == rule/build-prog.mk == * Add guards for "disabled-$(dir)-$(stage)" around the rule body == mk/build.mk.default == * Add a set of package disabling definitions when $(Stage1Only) is set to "YES" == rts/ghc.mk == * Add the all_rts target as a dependency for all, causing the rts to build when packages that depend on it are disabled -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7841> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7726: unexpected out of memory error on FreeBSD
by GHC 11 May '13

11 May '13

#7726: unexpected out of memory error on FreeBSD -------------------------------+-------------------------------------------- Reporter: nejstastnejsistene | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.4.2 | Keywords: Os: FreeBSD | Architecture: x86 Failure: Runtime crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- I wrote a daemon that periodically scrapes information from a webpage that crashes after about 20 hours with the error: "out of memory (requested 1048576 bytes)". The program runs fine on my Ubuntu machine, but always crashes on FreeBSD even though there is plenty of memory to spare/memory stays constant/etc. I boiled it down to the following code, which consistently crashes after about 4000-6000 iterations when compiled with -O2, and about 35000 without. {{{ import Data.Conduit import Data.Conduit.List import qualified Data.ByteString as B import Network.HTTP.Conduit main :: IO () main = do manager <- newManager def loop manager 1 loop :: Manager -> Int -> IO () loop manager i = do putStrLn $ show i request <- parseUrl "http://localhost:8000/courselist.html" html <- runResourceT $ do response <- http request manager fmap B.concat $ responseBody response $$+- consume loop manager $ i + 1 }}} For debugging, I served a copy of of a typical html sample from localhost using "python -m SimpleHTTPServer". The html file is attached. Sample Output:[[BR]] {{{ ... 35361 35362 35363 35364 35365 main: out of memory (requested 1048576 bytes) }}} Other information: {{{ $ uname -a FreeBSD oriskova 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec 4 06:55:39 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 }}} {{{ $ gcc -v Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: posix[[BR]] gcc version 4.2.1 20070831 patched [FreeBSD] }}} I wasn't sure if I should submit this or not since it seemed fairly specific to http-conduit, but the wiki said to go ahead and submit runtime errors, so that's what I did. This is my first time ever submitting a bug report and I tried my best to follow all the instructions at [http://hackage.haskell.org/trac/ghc/wiki/ReportABug] but please tell me if there is something I'm doing wrong. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7726> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6