November 2013 - ghc-tickets

[GHC] #8298: +RTS -hb crash when blocking on empty TChan
by GHC 14 Nov '13

14 Nov '13

#8298: +RTS -hb crash when blocking on empty TChan ------------------------------------------------+-------------------------- Reporter: exFalso | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: biographical stm tchan block | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Difficulty: Unknown | Runtime crash Blocked By: | Test Case: Related Tickets: | Blocking: ------------------------------------------------+-------------------------- Running the following code {{{ module Main where import Control.Concurrent import Control.Concurrent.STM main :: IO () main = do c <- newTChanIO forkIO . atomically $ readTChan c return () }}} produces: {{{ $ ./tmp +RTS -hb tmp: internal error: Invalid object in processHeapClosureForDead(): 0 (GHC version 7.6.3 for x86_64_unknown_linux) }}} It crashes without forkIO as well, I inserted it so that a plain run doesn't result in "thread blocked indefinitely in an STM transaction". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8515: Biographical profiling (-hb) crashes, other profiling modes have truncated output
by GHC 14 Nov '13

14 Nov '13

#8515: Biographical profiling (-hb) crashes, other profiling modes have truncated output ----------------------------------+---------------------------------- Reporter: blitzcode | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I have a (non-trivial) threaded program which always crashes with a Bus Error when running with +RTS -hb. gdb didn't provide much useful information. Valgrind seems to have some issues with Haskell programs, but here is what it spits out: jacky: ioManagerDie: write: Bad file descriptor ==56255== Invalid read of size 4 ==56255== at 0x1AAC4BD: LdvCensusForDead (in ./jacky) ==56255== by 0x1ABBAAC: scheduleDoGC (in ./jacky) ==56255== by 0x1ABBEBE: exitScheduler (in ./jacky) ==56255== Address 0x9c88090 is 0 bytes inside a block of size 8 free'd ==56255== at 0x3E7511F: realloc (vg_replace_malloc.c:525) ==56255== by 0x1AB9E77: stgReallocBytes (in ./jacky) ==56255== ==56255== Invalid read of size 4 ==56255== at 0x1AAC4BD: LdvCensusForDead (in ./jacky) ==56255== Address 0x9c88090 is 0 bytes inside a block of size 8 free'd ==56255== at 0x3E7511F: realloc (vg_replace_malloc.c:525) ==56255== by 0x1AB9E77: stgReallocBytes (in ./jacky) ==56251== Invalid read of size 4 ==56251== at 0x1AAC4BD: LdvCensusForDead (in ./jacky) ==56251== by 0x1ABBAAC: scheduleDoGC (in ./jacky) ==56251== by 0x1ABBEBE: exitScheduler (in ./jacky) ==56251== Address 0x9c88090 is 0 bytes inside a block of size 8 free'd ==56251== at 0x3E7511F: realloc (vg_replace_malloc.c:525) ==56251== by 0x1AB9E77: stgReallocBytes (in ./jacky) ==56251== ==56251== Invalid read of size 4 ==56251== at 0x1AAC4BD: LdvCensusForDead (in ./jacky) ==56251== Address 0x9c88090 is 0 bytes inside a block of size 8 free'd ==56251== at 0x3E7511F: realloc (vg_replace_malloc.c:525) ==56251== by 0x1AB9E77: stgReallocBytes (in ./jacky) running with +'RTS -hb -s' gets us this from valgrind: jacky(56272,0xa0707540) malloc: *** error for object 0x4c05684: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug jacky(56272,0xa0707540) malloc: *** error for object 0x4c03894: incorrect checksum for freed object - object was probably modified after being freed. ... The program seems to work just fine when running without profiling. Profiling modes other than -hb haven't crashed so far, but it seems the output is truncated. Cost-center profiling seems to work the most reliable, but all the other memory profiling options only output data for the first few seconds, even when the program runs for minutes. I haven't managed to narrow this one down further in the program, please let me know if this is already helpful or if I need to provide more information. I also attached the OS X crash report file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8515> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8530: ghc: Unknown PEi386 section name `.drectve'
by GHC 14 Nov '13

14 Nov '13

#8530: ghc: Unknown PEi386 section name `.drectve' ----------------------------+------------------------------------- Reporter: jamer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+------------------------------------- Hello, Bug: - GHC crashes when running "cabal install scion-browser". Expected result: - scion-browser builds and installs successfully. Steps to reproduce: - Install Haskell Platform 2013.02.0.0 - cabal update - cabal install cabal-install - cabal install scion-browser I have not tried to reproduce this problem outside of 32-bit Windows 7. A log of the output from "cabal install scion-browser" is attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8530> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 13 Nov '13

13 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by duncan): @andersk just to play devil's advocate for a moment: why not use negative encoding for signals, and just ignore the core dump bit? It gives an encoding that is very simple to use and very few people care about core dumps (and if they do, they can use the unix package). `-n` is a lot easier than {{{(n .&. 0x7f00) `shiftR` 8}}}. Indeed people are likely to do it wrong and just use {{{n `shiftR` 8}}} in which case they'll get tripped up whenever there is a core dump (which is platform configuration specific). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7229: Detecting if a process was killed by a signal is impossible
by GHC 13 Nov '13

13 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by duncan): Heh, turns out python switched to using -N for signals. See popen. http://docs.python.org/2/library/subprocess.html#subprocess.Popen.returncode -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
by GHC 13 Nov '13

13 Nov '13

#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8 -------------------------+------------------------------------------------- Reporter: | Owner: dylukes | Status: closed Type: bug | Milestone: 7.4.2 Priority: high | Version: 7.4.1 Component: | Keywords: rts, strange closure, Runtime System | internal error, os x Resolution: | Architecture: x86_64 (amd64) worksforme | Difficulty: Unknown Operating System: | Blocked By: MacOS X | Related Tickets: Type of failure: | Runtime crash | Test Case: | Blocking: | -------------------------+------------------------------------------------- Comment (by simonmar): CoreyOConnor: this particular error message indicates general corruption in the heap, and has many different causes. This particular ticket turned out to be a bug in the XCode linker, which went away subsequently. Please open a separate ticket. My educated guess is that your bug will turn out to be something related to the plugins package that yi uses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5899#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8198: One-shot mode is buggy w.r.t. hs-boot files
by GHC 13 Nov '13

13 Nov '13

#8198: One-shot mode is buggy w.r.t. hs-boot files -------------------------+------------------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: | Milestone: 7.8.1 normal | Version: 7.7 Component: | Operating System: Unknown/Multiple Driver | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Consider === A.hs-boot {{{ #!haskell module A where }}} === B.hs {{{ #!haskell module B where import {-# SOURCE #-} A }}} === Command Line {{{ $ ghc -c A.hs-boot B.hs B.hs:3:1: Bad interface file: A.hi-boot-boot A.hi-boot-boot: openBinaryFile: does not exist (No such file or directory) }}} I expect the modules to get compiled cleanly. Instead I get an error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8521: Tight loop prevents other threads from running in available cores
by GHC 13 Nov '13

13 Nov '13

#8521: Tight loop prevents other threads from running in available cores -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The following program does not terminate when compiled with: {{{ghc --make -O -threaded test.hs}}} and executed on linux on an amd64 machine with 16 cores with: {{{./test}}} {{{ import Control.Concurrent import Control.Monad import System.Environment main :: IO () main = do y <- getArgs mv0 <- newEmptyMVar mv1 <- newEmptyMVar forkIO $ do takeMVar mv0 putMVar mv1 () loop (y == ["yield"]) putMVar mv0 () takeMVar mv1 >>= print loop :: Bool -> IO () loop cooperative = go where go = when cooperative yield >> go }}} Here [1] is the discussion about it so far. [1] http://www.haskell.org/pipermail/glasgow-haskell- users/2013-October/024412.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8521> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4268: Warning for ANN pragmas when GHCi is not supported
by GHC 13 Nov '13

13 Nov '13

#4268: Warning for ANN pragmas when GHCi is not supported -------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.0.4 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: #8312, #5105 Blocking: | -------------------------------+------------------------------------------- Comment (by simonmar): Might have been slightly better to say "this is a stage-1 compiler or doesn't support GHCi" or somesuch, because some platforms just don't support GHCi. Not a big deal though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4268#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5996: fix for CSE
by GHC 12 Nov '13

12 Nov '13

#5996: fix for CSE -------------------------------------------------+------------------------- Reporter: michalt | Owner: Type: bug | simonpj Priority: normal | Status: Component: Compiler | closed Resolution: fixed | Milestone: 7.8.1 Operating System: Unknown/Multiple | Version: 7.5 Type of failure: Runtime performance bug | Keywords: Test Case: | Architecture: simplCore/should_compile/T5996 | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Changes (by simonpj): * status: patch => closed * testcase: => simplCore/should_compile/T5996 * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5996#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0