- ghc-tickets - Haskell.org

Re: [GHC] #1851: "make install-strip" should work
by GHC 26 Jan '15

26 Jan '15

#1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): Still a problem in 7.10.1 RC1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1851#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1851: "make install-strip" should work
by GHC 26 Jan '15

26 Jan '15

#1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * version: 7.8.4-rc1 => 7.9 * milestone: => 7.10.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1851#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

25 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: | -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:6 goldfire]: > But, with 7.10, the following doesn't: > > {{{ > type family F a where > F a = F a > > id2 :: F a -> F a > id2 x = x > }}} > > This is slightly disturbing because `id2` is merely a specialization of `id`. I think this is wrong: `id2` does not have a type at all, and therefore does not specialize `id`. The same is true for the original example. If one looks at the code generated by ghc-7.8.3, it tries to produce a witness for {{{F (Fix Id)}}} being a type, and `foo` checks that witness (which fails, producing the observed {{{<<loop>>}}}) before producing `undefined`: {{{ -- core, with some non-essential parts omitted cobox_rVz :: Main.F (Main.Fix Main.Id) ~ GHC.Prim.Any cobox_rVz = cobox_rVz foo :: Main.Proxy (Main.F (Main.Fix Main.Id)) -> () foo = case cobox_rVz of GHC.Types.Eq# _ -> undefined }}} That said it's unfortunate that GHC 7.10 loops rather than erroring out for these examples. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10015: Give the DLL loader awareness of rpaths
by GHC 24 Jan '15

24 Jan '15

#10015: Give the DLL loader awareness of rpaths -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: None/Unknown Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is nix-related. I'm trying to build with the nix version of libiconv instead of system libiconv, and to facilitate this I'm running package builds in a sandbox. If I try to compile a module using TemplateHaskell, say {{{#!hs module Main where main :: IO () main = putStrLn $([|"Hello, world!"|]) }}} I get this from ghc --make: [1 of 1] Compiling Main ( main.hs, main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... <command line>: can't load .so/.DLL for: libiconv.dylib (dlopen(libiconv.dylib, 9): no suitable image found. Did find: /usr/lib/libiconv.dylib: stat() failed with errno=1) When of course I'd rather it just try to dlopen /nix/store /lsvxsyw9w17d2rix740akjxyxcacgi3k-libiconv-41/lib/libiconv.dylib, the one it was built with. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10015> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error
by GHC 24 Jan '15

24 Jan '15

#9867: PatternSynonyms + ScopedTypeVariables triggers an internal error -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When trying to give a type signature with a free type variable to a pattern in a pattern synonym, GHC dies with an internal error. Given the file {{{#!hs {-# LANGUAGE PatternSynonyms, ScopedTypeVariables #-} pattern Nil = [] :: [a] }}} the resulting error is {{{ Example.hs:2:22: GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer … tcl_env of environment: [] In an expression type signature: [a] In the expression: [] :: [a] In an equation for ‘$WNil’: $WNil = [] :: [a] Compilation failed. }}} The fix is to add `RankNTypes` and an explicit `forall`: {{{#!hs {-# LANGUAGE PatternSynonyms, ScopedTypeVariables, RankNTypes #-} pattern Nil = [] :: forall a. [a] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9867> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one
by GHC 23 Jan '15

23 Jan '15

#9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Steps to reproduce: Build GHC using 7.10 as the bootstrapping compiler. Now check which GHC package stage 1 Main.hi was linked against, e.g. using `--show-iface`: {{{ [ezyang@hs01 ghc-validate2]$ ../ghc-7.10/inplace/bin/ghc-stage2 --show- iface ghc/stage1/build/Main.hi ... package dependencies: array-0.5.0.1 base-4.8.0.0 binary-0.7.2.3 bin-package-db-0.0.0.0 bytestring-0.10.6.0 containers-0.5.6.2 deepseq-1.4.0.0 directory-1.2.1.1 filepath-1.3.1.0 ghc-7.10.0.20141223 ghc-prim-0.3.1.0 hoopl-3.10.0.2 hpc-0.6.0.2 integer-gmp-1.0.0.0 process-1.2.1.0 time-1.5.0.1 transformers-0.4.2.0 unix-2.7.1.0 }}} Bad news! I think I introduced bug when I made GHC a wired in package: consequently when we ask GHC to link against a specific version of the GHC package, this flag is ignored. I don't actually know what the right way to fix this is, but we'll have to figure something out here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9856: Test suite regressions due to integer-gmp2
by GHC 23 Jan '15

23 Jan '15

#9856: Test suite regressions due to integer-gmp2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: prof-doc- | fib linker_unload | Blocking: | Differential Revisions: Phab:D82 -------------------------------------+------------------------------------- According to my performance builders, changeset:c774b28/ghc (Phab:D82) caused prof-doc-fib and linker_unload to fail on both performance builders (Ubuntu 13.10 and Ubuntu 14.04): {{{ Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: linker_unload: /home/nomeata/logs/ghc-tmp-REV/libraries/integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a: unknown symbol `__gmpn_rshift' linker_unload: resolveObjs failed make[3]: *** [linker_unload] Error 1 *** unexpected failure for linker_unload(normal) }}} and {{{ Actual prof output differs from expected: --- ./profiling/should_run/prof-doc-fib.prof.sample 2014-12-01 15:30:19.000000000 +0100 +++ ./profiling/should_run/prof-doc-fib.prof 2014-12-01 15:56:08.000000000 +0100 @@ -1,9 +1,9 @@ - Thu Oct 27 09:29 2011 Time and Allocation Profiling Report (Final) + Mon Dec 1 15:56 2014 Time and Allocation Profiling Report (Final) - fib +RTS -p -RTS + prof-doc-fib +RTS -hc -p -RTS - total time = 0.76 secs (38 ticks @ 20 ms) - total alloc = 247,940,020 bytes (excludes profiling overheads) + total time = 0.14 secs (135 ticks @ 1000 us, 1 processor) + total alloc = 107,829,304 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc @@ -13,13 +13,16 @@ individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc -MAIN MAIN 102 0 0.0 0.0 100.0 100.0 - CAF Main 203 0 0.0 0.0 100.0 100.0 - main Main 204 1 0.0 0.0 100.0 100.0 - main.g Main 207 1 0.0 0.0 0.0 0.1 - fib Main 208 1973 0.0 0.1 0.0 0.1 - main.f Main 205 1 0.0 0.0 100.0 99.9 - fib Main 206 2692537 100.0 99.9 100.0 99.9 - CAF GHC.Conc.Signal 201 0 0.0 0.0 0.0 0.0 - CAF GHC.IO.Encoding.Iconv 191 0 0.0 0.0 0.0 0.0 - CAF GHC.IO.Handle.FD 183 0 0.0 0.0 0.0 0.0 +MAIN MAIN 45 0 0.0 0.0 100.0 100.0 + main Main 91 0 0.0 0.0 0.0 0.0 + CAF Main 89 0 0.0 0.0 100.0 100.0 + main Main 90 1 0.0 0.0 100.0 100.0 + main.f Main 94 1 0.0 0.0 100.0 99.9 + fib Main 95 2692537 100.0 99.9 100.0 99.9 + main.g Main 92 1 0.0 0.0 0.0 0.1 + fib Main 93 1973 0.0 0.1 0.0 0.1 + CAF GHC.IO.Handle.Text 86 0 0.0 0.0 0.0 0.0 + CAF GHC.IO.Handle.FD 82 0 0.0 0.0 0.0 0.0 + CAF GHC.Conc.Signal 78 0 0.0 0.0 0.0 0.0 + CAF GHC.IO.Encoding 76 0 0.0 0.0 0.0 0.0 + CAF GHC.IO.Encoding.Iconv 75 0 0.0 0.0 0.0 0.0 *** unexpected failure for prof-doc-fib(profasm) }}} The former is also observed by SPJ. The latter actually looks less like a regression, and more an improvement – maybe Herbert simply did not run a profiled version when updating test results? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9856> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9949: zipWith too strict in second argument in GHC-7.10.0
by GHC 23 Jan '15

23 Jan '15

#9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1-rc1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- correct: {{{ $ ghci-7.8.4 -Wall Prelude> zipWith (==) "" undefined [] }}} incorrect: {{{ $ ghci-7.10.0.20141227 -Wall Prelude> zipWith (==) "" undefined *** Exception: Prelude.undefined }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9949> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

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

23 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