December 2014 - ghc-tickets

[GHC] #9767: Add isSubsequenceOf to Data.List
by GHC 05 Feb '15

05 Feb '15

#9767: Add isSubsequenceOf to Data.List -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Niklas Hambüchen suggested that we add the dual of subsequences, isSubsequenceOf (like isPrefixOf to inits & isSuffixOf to tails)[1]. It was a simple and noncontroversial proposal which received unanimous +1s. [1] https://www.haskell.org/pipermail/libraries/2014-November/024063.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9767> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8266: Dynamic linking on Mac
by GHC 04 Feb '15

04 Feb '15

#8266: Dynamic linking on Mac ------------------------------+-------------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: Priority: highest | Version: 7.7 Component: Build | Operating System: MacOS X System | Type of failure: GHC doesn't work at all Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Many dynamic libraries refer to the build tree. (1) Every ".dylib" installed with GHC head refers to itself in its build directory. E.g. {{{ % otool -L libHSbase-4.7.0.0-ghc7.7.20130909.dylib | grep base libHSbase-4.7.0.0-ghc7.7.20130909.dylib: /Users/kazu/work/ghc/libraries/base/dist- install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) }}} (2) Some ".dylib" installed with GHC head refers to other libraries in their build directories. E.g. {{{ % otool -L libHSvector-0.9.1-ghc7.7.20130909.dylib | grep /Users /Users/kazu/work/ghc/libraries/vector/dist- install/build/libHSvector-0.9.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/primitive/dist- install/build/libHSprimitive-0.4.0.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) }}} (3) All user installed libraries by cabal-install refer to other libraries in their build directories. E.g. {{{ % otool -L libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib| grep Users /Users/kazu/Library/Haskell/ghc-7.7.20130909/lib/ghc- paths-0.1.0.9/lib/libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/base/dist- install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/integer-gmp/dist-install/build /libHSinteger-gmp-0.5.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/kazu/work/ghc/libraries/ghc-prim/dist-install/build /libHSghc-prim-0.3.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8266> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 59

[GHC] #9937: add updated prefetch API mention to the 7.10 release notes
by GHC 02 Feb '15

02 Feb '15

#9937: add updated prefetch API mention to the 7.10 release notes -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9937> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit()
by GHC 02 Feb '15

02 Feb '15

#9423: shutdownCapability sometimes loops indefinitely on OSX after hs_exit() -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: 9284 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Issue #9284 relates to `forkProcess`, which previously invoked the same code that is invoked by `hs_exit` and uncovered this problem. The resolution of #9284 is to not invoke the equivalent of `hs_exit` (for reasons that you can see in #9284). However, `hs_exit` can be called by programs that explicitly create and teardown a Haskell runtime, so the problem displayed by #9284 can still occur for those programs. The problem has only been observed on OS X, though it probably could occur on Linux OSes as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9423> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9928: Wrong information about the version of the time library in the release notes of various versions of GHC
by GHC 28 Jan '15

28 Jan '15

#9928: Wrong information about the version of the time library in the release notes of various versions of GHC -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The information about the version of the time library is wrong in the release notes of [https://downloads.haskell.org/~ghc/7.10.1-rc1/docs/html/users_guide/release… GHC 7.10.1], [https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/release-7-8-… GHC 7.8.3] and [https://downloads.haskell.org/~ghc/7.6.1/docs/html/users_guide/release-7-6-… GHC 7.6.1]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9928> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9935: Can't compile rts/StgCRun.c for aarch64-linux
by GHC 28 Jan '15

28 Jan '15

#9935: Can't compile rts/StgCRun.c for aarch64-linux ----------------------------+---------------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: Other | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+---------------------------------------------- When cross-compiling from x86_64-linux to aarch64-linux I get: {{{ rts/StgCRun.c: In function ‘StgRun’: rts/StgCRun.c:756:5: error: unknown register name ‘%lr’ in ‘asm’ __asm__ volatile ( }}} It seems the asm code here is for iOS and does not work for Linux. Have a patch in progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9935> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

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

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