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

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

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

[GHC] #7684: cgrun071 segfaults
by GHC 03 May '13

03 May '13

#7684: cgrun071 segfaults --------------------------+------------------------------------------------- Reporter: tibbe | Owner: tibbe Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: MacOS X | Architecture: x86_64 (amd64) Failure: Runtime crash | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- I ran into this working on something unrelated today: {{{ =====> cgrun071(normal) 171 of 3449 [0, 0, 12] cd ./codeGen/should_run && '/Users/tibbe/src/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-ghci-history -o cgrun071 cgrun071.hs >cgrun071.comp.stderr 2>&1 cd ./codeGen/should_run && ./cgrun071 </dev/null >cgrun071.run.stdout 2>cgrun071.run.stderr /bin/sh: line 1: 37450 Segmentation fault: 11 ./cgrun071 < /dev/null > cgrun071.run.stdout 2> cgrun071.run.stderr Wrong exit code (expected 0 , actual 139 ) Stdout: Stderr: *** unexpected failure for cgrun071(normal) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #7720: iOS patch no 9: Linking
by GHC 28 Apr '13

28 Apr '13

#7720: iOS patch no 9: Linking ------------------------------+--------------------------------------------- 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: ------------------------------+--------------------------------------------- These are all the changes necessary to make the iOS cross compiler link in the right way for iOS. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7720> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #7723: iOS patch no 12: Itimer.c doesn't work on iOS
by GHC 27 Apr '13

27 Apr '13

#7723: iOS patch no 12: Itimer.c doesn't work on iOS ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Other | Architecture: arm Failure: None/Unknown | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- As it stands, rts/posix/Itimer.c dies at runtime on iOS. I am in the process of tidying up a solution for this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #7652: Testing freezes on FreeBSD 9.1.
by GHC 24 Apr '13

24 Apr '13

#7652: Testing freezes on FreeBSD 9.1. --------------------------+------------------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: FreeBSD | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: --------------------------+------------------------------------------------- "gmake THREADS=10 fast" in the testsuite/tests directory does not finish. The following processes use CPU 100%: * 367_letnoesca * throwto001 * Chan002 * ghc-stage2 compiling conc070.hs The following process is waiting for something forever: * signals004 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #7650: can't use combining characters in identifiers
by GHC 23 Apr '13

23 Apr '13

#7650: can't use combining characters in identifiers -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Linux | Architecture: x86 Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- ghc doesn't let me use combining characters in unicode identifiers. Here's a test case with U+308 (COMBINING DIAERESIS) but it affects all accents: {{{ % cat comb.hs main = print spın̈alTap where spın̈alTap = 11 }}} {{{ % ghc comb.hs [1 of 1] Compiling Main ( comb.hs, comb.o ) comb.hs:1:18: lexical error at character '\776' }}} (This is actually with ghc 7.6.2 but the `Version` drop-down only goes up to 7.6.1.) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3