- ghc-tickets - Haskell.org

Re: [GHC] #4175: GHCi support for type/data families should match that of related features
by GHC 15 Nov '13

15 Nov '13

#4175: GHCi support for type/data families should match that of related features ---------------------------------------+----------------------------------- Reporter: claus | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.3 Resolution: fixed | Keywords: FD TF Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: ghci/scripts/T4175 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ---------------------------------------+----------------------------------- Comment (by Patrick Palka <patrick@…>): In [changeset:"eb8fb434ff5e962a54247cacc5d3340972d5daf4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="eb8fb434ff5e962a54247cacc5d3340972d5daf4" Simplify and improve coverage of ":info" instance lookup During instance lookup, we can treat classes and data families like any other TyCon instead of special-casing them. This approach, aside from being simpler, has the benefit of returning extra relevant instances for classes and data families. For example, given class A a instance B (a :: Constraint) instance A B ":info B" will now also print "instance A B" where previously it didn't due to the special casing of class TyCons in lookupInsts. This improves upon the existing patch for Trac #4175 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4175#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2301: Proper handling of SIGINT/SIGQUIT
by GHC 14 Nov '13

14 Nov '13

#2301: Proper handling of SIGINT/SIGQUIT -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: | Version: 6.12.3 libraries/process | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: POSIX | Difficulty: Unknown Type of failure: Incorrect result | Blocked By: at runtime | Related Tickets: Test Case: | #3994,#5766,#7229,#4274,#3318,#1619 Blocking: | -------------------------------------+------------------------------------- Comment (by duncan): I have a patch to fix this. It adds a new `delegate_ctlc :: Bool` to the `CreateProcess` options record for delegating control C handling. If you turn that on, then `createProcess` will make the parent process ignore SIGINT until `waitForProcess` returns (or `getProcessExitCode` returns non-Nothing). Then `waitForProcess` (or `getProcessExitCode`) will throw `UserInterrupt` if we were delegating, and the process did exit due to SIGINT. This should implement the "WCE" protocol ok. It should correctly handle the case of there being multiple concurrent processes to which we're delegating (unlike the current `system`/`rawSystem` which will end up with the wrong signal handlers installed). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2301#comment:34> 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 14 Nov '13

14 Nov '13

#7229: Detecting if a process was killed by a signal is impossible --------------------------------------+------------------------------------ Reporter: benmachine | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: libraries/process | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by duncan): * status: new => closed * resolution: => fixed Comment: So I've pushed patches to process, base and the rts to implement this, using the -signum encoding. * process [changeset:"3ebbe13a82b4f4beb382bb8a07f98e57a8354a85/process"] * base [changeset:"6b22a6ef9e59c6562ef6adfad7cd94e27aedec2c/base"] * ghc [changeset:"a987b8004e83c694e00cdd47cbf43a9588eb47d4/ghc"] There's also haddock docs, and tests (in separate commits). I think we can declare this done. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7229#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8531: ghc crash from kinds
by GHC 14 Nov '13

14 Nov '13

#8531: ghc crash from kinds -----------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- When I run this in ghci: {{{ let x :: MaybeT IO (Ptr Int); x = (lift newCString "hi") >>= nullableToMaybeT }}} I get this output: {{{ Couldn't match kind `* -> *' with `*' Expected type: [Char] -> MaybeT IO (Ptr Int) Actual type: [Char] -> MaybeT IO (Ptr Int) Kind incompatibility when matching types: [Char] :: * -> * [Char] :: * The function `lift'ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-apple-darwin): kindFunResult <<details unavailable>> }}} where nullToMaybeT is: {{{ nullableToMaybeT :: Monad m => Ptr a -> MaybeT m (Ptr a) nullableToMaybeT ptr = do case (ptr == nullPtr) of True -> (MaybeT . return) Nothing False -> return ptr }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8531> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #3693: Show stack traces
by GHC 14 Nov '13

14 Nov '13

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Tarrasch): * cc: miffoljud@…, simonmar (added) * owner: => Tarrasch * milestone: 7.6.2 => 7.10.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:50> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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