January 2015 - ghc-tickets

[GHC] #10013: GHC 7.8.4 panics while building "vty" library test suite
by GHC 22 Jan '15

22 Jan '15

#10013: GHC 7.8.4 panics while building "vty" library test suite -------------------------------------+------------------------------------- Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ Linking dist/build/verify-attribute-opsStub/verify-attribute-opsStub ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Don't understand library name verify-attribute-ops }}} A complete build log is available at http://hydra.nixos.org/build/18786125/log/raw. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10013> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess
by GHC 22 Jan '15

22 Jan '15

#9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The attached Haskell program is a stress test for `forkProcess`. It starts 100 child processes, each of which do a single, safe, FFI call, after which the main process waits for all child processes to terminate. I compile the test with {{{ # gcc -c -o TestForkProcessC.o -g TestForkProcessC.c # ghc -debug -threaded -fforce-recomp -Wall TestForkProcess.hs TestForkProcessC.o }}} and then start running it until it fails (that is, until one or more of the child processes fail to terminate): {{{ # while ./TestForkProcess +RTS -N1 ; do echo "OK"; done }}} Actually, most of the time this happens pretty quickly (often even on the first call to `TestForkProcess`). Those child processes that do fail to terminate get stuck in an infinite loop in `shutdownCapability`, which looks something like: {{{ void shutdownCapability (Capability *cap, Task *task, rtsBool safe) { nat i; task->cap = cap; for (i = 0; /* i < 50 */; i++) { // ... other conditionals omitted if (cap->suspended_ccalls && safe) { cap->running_task = NULL; RELEASE_LOCK(&cap->lock); // The IO manager thread might have been slow to start up, // so the first attempt to kill it might not have // succeeded. Just in case, try again - the kill message // will only be sent once. ioManagerDie(); yieldThread(); continue; } traceSparkCounters(cap); RELEASE_LOCK(&cap->lock); break; } } }}} (note that I'm only considering the threaded RTS). In the child processes that loop indefinitely this `cap->suspended_ccalls && safe` condition gets triggered time and again. When it does, it gets stuck waiting for a single `InCall`. This `InCall` is created by a call to `newInCall` in `workerStart` -- i.e., it is created on pthread startup. That begs the question where this worker task was created; this I don't know for sure but I am fairly sure that it happens during the initialization of the IO manager. (The initialization sequence of the IO manager involves the creation of 4 tasks before we even get to `main`, so it's bit a hard to navigate.) I have some further evidence that the I/O manager is involved, although not necessarily the cause of the problem. On normal termination, the I/O manager is asked to shutdown by the call to `ioManagerDie` in `shutdownCapability`, shown above. This will send `IO_MANAGER_DIE` (`0xFE`) on the I/O managers "control pipe" (created in `GHC.Event.Thread.startTimerManagerThread`). When the timer manager thread receives this (in `GHC.Event.TimerManager.handleControlEvent`) it calls `shutdownManagers`, which shuts down the IO manager threads by sending them `io_MANAGER_DIE` on their respective pipes. This gets received by `GHC.Event.Manager.handleControlEvent` and the IO manager threads exit. (Note on capitalization: `IO_MANAGER_DIE` is the C symbol; `io_MANAGER_DIE` is the Haskell symbol.) When the child process fails to terminate, the first part of this process still happens. The timer manager thread receives `IO_MANAGER_DIE` and calls `shutdownManagers`. However, now things go wrong, and it seems they go wrong in one of two ways. The very first thing that `shutdownManagers` does is acquire the `ioManagerLock`. Sometimes it gets stuck right there. However, this is not ''always'' the case. Sometimes it does manage to acquire the lock, and I can see it going through the loop and sending the shutdown signal to the IO manager thread (I'm saying "the" because I've exclusively been testing with `-N1`). Either way, in the case that the child process gets stuck, this signal somehow never arrives at the IO manager thread (that is, I have a print statement in `readControlMessage` that prints a message when it receives `IO_MANAGER_DIE`, along with a bit of information where it was called from, and that print statement never triggers). I am not sure where to go from here. Note that I have only been able to reproduce this on OSX/ghc 7.8. I have not been able to reproduce this problem on Linux/7.8 (although there _are_ other problems with `forkProcess` on Linux, which unfortunately are proving even more elusive). The attached stress test ''does'' very often get stuck on Linux/7.4 but of course that's a different I/O manager altogether and is probably an unrelated bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9284> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9990: Top level module identifiers shadow imported identifiers
by GHC 20 Jan '15

20 Jan '15

#9990: Top level module identifiers shadow imported identifiers -------------------------------------+------------------------------------- Reporter: drb226 | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Let's try this out as a language pragma and see if we like it? Artificial example: {{{#!hs {-# LANGUAGE TopLevelShadowsImports #-} import Data.Monoid (<>) = mappend main = putStrLn ("Hello" <> " " <> "World") }}} Current behavior: error: ambiguous occurrence of (<>) Desired behavior: uses top-level definition of (<>), prints "hello world" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9990> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10008: Error
by GHC 20 Jan '15

20 Jan '15

#10008: Error -------------------------------------+------------------------------------- Reporter: | Owner: amadeusxnet | Status: new Type: bug | Milestone: Priority: normal | Version: 7.4.1 Component: Compiler | Operating System: Linux Keywords: | Type of failure: Building GHC Architecture: arm | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for arm-unknown-linux): Cant do annotations without GHCi {Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} base:GHC.Exts.ForceSpecConstr{d raqj} I'm using a Raspberry Pi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10008> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 20 Jan '15

20 Jan '15

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9999: Typeable deriving behavior different between data families and associated data types
by GHC 19 Jan '15

19 Jan '15

#9999: Typeable deriving behavior different between data families and associated data types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- With `AutoDeriveTypeable`, data families get a `Typeable` instance, but associated data types in a class don't (and even standalone deriving doesn't work for them). {{{ λ> data family Foo a λ> typeRep (Proxy :: Proxy Foo) Foo λ> class K a where { data Bar a } λ> typeRep (Proxy :: Proxy Bar) <interactive>:6:1: No instance for (Typeable Bar) arising from a use of ‘typeRep’ In the expression: typeRep (Proxy :: Proxy Bar) In an equation for ‘it’: it = typeRep (Proxy :: Proxy Bar) λ> deriving instance Typeable Bar <interactive>:7:1: Can't make a derived instance of ‘Typeable Bar’: Deriving Typeable is not allowed for family instances; derive Typeable for ‘Bar’ alone In the stand-alone deriving instance for ‘Typeable Bar’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9999> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9836: Facility to mitigate double-breakage due to Data.Version.versionTag Deprecation
by GHC 19 Jan '15

19 Jan '15

#9836: Facility to mitigate double-breakage due to Data.Version.versionTag Deprecation -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: libraries/base | Version: Keywords: Data.Version | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: #2496 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- See https://groups.google.com/forum/#!topic/haskell-core-libraries/q9H- QlL_gnE -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9836> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] Batch modify: #7919, #8131, #8974, #9007, #314, #781, #4144, #4505, #5987, #7325, #7411, #7521, #7567, #7679, #8228, #5910, #9631
by GHC 19 Jan '15

19 Jan '15

Batch modification to #7919, #8131, #8974, #9007, #314, #781, #4144, #4505, #5987, #7325, #7411, #7521, #7567, #7679, #8228, #5910, #9631 by thoughtpolice: milestone to 7.12.1 Comment: Moving to 7.12.1 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=7919%2C8131%2C8974%2C9007%2C314%2C…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7320: GHC crashes when building on 32-bit Linux in a Linode
by GHC 19 Jan '15

19 Jan '15

#7320: GHC crashes when building on 32-bit Linux in a Linode ---------------------------------------+----------------------------------- Reporter: benl | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * priority: high => normal * milestone: 7.10.1 => 7.12.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7320#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7298: Test 2228 fails with dynamic-by-default
by GHC 19 Jan '15

19 Jan '15

#7298: Test 2228 fails with dynamic-by-default -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: GHCi | Version: 7.6.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7298#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0