July 2014 - ghc-tickets

[GHC] #8785: Replace hooks API in the RTS with something better
by GHC 16 Jun '15

16 Jun '15

#8785: Replace hooks API in the RTS with something better ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hooks rely on static linking behaviour which doesn't always work: we have to disable -Bsymbolic for the RTS on Linux (see `compiler/main/SysTools.lhs`) and it apparently doesn't work at all on Mac (#8754). So instead of hooks we should be passing in information when we initialize the RTS, like we already do for some other things (`-rtsopts` etc.). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8785> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files
by GHC 14 Jun '15

14 Jun '15

#8591: Concurrent executions of ghc-pkg can cause inconstant package.cache files ------------------------------------+---------------------------- Reporter: janm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.6.3 Keywords: ghc-pkg race | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------- I am doing 24 way parallel builds of system images, including all packages on a system. This includes ghc and multiple ghc packages. I am seeing intermittent dependency failure from the ghc packaging system. From examining Main.hs in ghc-pkg, I see the function withFileAtomic write to a temporary file in package.conf.d and then atomically rename on top of a target file, package.cache in the case. With parallel execution the last rename would win, leading to lost entries in package.cache. In my case, the following things happened: ("Building" indicates a start, "Built" indicates completion, "Installing" is setup in a separate chroot'd environment and is isolated) The FreeBSD ports system is used to drive the Haskell build system. The process works single threaded and fails intermittently when done in parallel. Building: devel/hs-data-default-instances-base Building: devel/hs-data-default-instances-containers Building: devel/hs-data-default-instances-old-locale Built: devel/hs-dlist Building: devel/hs-data-default-instances-dlist Built: devel/hs-temporary Built: jail-image-full Installing: system-image__jail-image-full Built: devel/hs-base64-bytestring Built: archivers/hs-zlib Building: security/hs-digest Built: devel/hs-syb Building: textproc/hs-hs-bibutils Building: textproc/hs-pandoc-types Built: devel/hs-utf8-string Built: devel/hs-data-default-instances-old-locale Built: devel/hs-data-default-instances-containers Built: devel/hs-data-default-instances-base Built: devel/hs-data-default-instances-dlist Building: devel/hs-data-default Built: devel/hs-random Installed: system-image__lang/ghc Installing: system-image__archivers/hs-zlib Installing: system-image__devel/hs-utf8-string Installing: system-image__devel/hs-syb Installing: system-image__devel/hs-base64-bytestring Installing: system-image__devel/hs-data-default-class Installing: system-image__devel/hs-dlist Installing: system-image__devel/hs-random Installing: system-image__devel/hs-temporary Installing: system-image__devel/hs-extensible-exceptions Built: devel/hs-data-default FAILED The error from the Haskell data-default build was: setup: At least the following dependencies are missing: data-default-instances-base -any Looking in the in the package.conf.d directory shows that the data- default-instances-base-0.0.1-7bdf8678f0d8637e096e397e7910f82a.conf file was present, but running "ghc-pkg list" did not show data-default- instances-base Running /usr/local/lib/cabal/ghc-7.6.3/data-default-instances- base-0.0.1/register.sh (which was also present) caused ghc-pkg to now show data-default-instances-base. To me this looks like a race condition between multiple instances of ghc- pkg causing the cache to become inconsistent. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8591> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8435: Do not copy stack after stack overflow
by GHC 12 Jun '15

12 Jun '15

#8435: Do not copy stack after stack overflow ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I am not sure, but I was doing a close reading of `threadStackOverflow` and noticed that after we throw a stack overflow exception, we fall through to the code responsible for allocating a new stack and copying the code over. An old iteration of the stack overflow code (removed in the commit cited below) did return after throwing the exception, and I did not see anything in the commit message suggesting the change was intentional. It seems sound to copy the stack; it will just become dead immediately. The relevant commit: {{{ commit f30d527344db528618f64a25250a3be557d9f287 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Wed Dec 15 12:08:43 2010 +0000 Implement stack chunks and separate TSO/STACK objects }}} Suggested (untested) patch: {{{ diff --git a/rts/Threads.c b/rts/Threads.c index 742119d..ccd6b17 100644 --- a/rts/Threads.c +++ b/rts/Threads.c @@ -533,6 +533,7 @@ threadStackOverflow (Capability *cap, StgTSO *tso) // Send this thread the StackOverflow exception throwToSingleThreaded(cap, tso, (StgClosure *)stackOverflow_closure); + return; } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8435> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9252: Generalize hs-boot files to be more like module signatures
by GHC 11 Jun '15

11 Jun '15

#9252: Generalize hs-boot files to be more like module signatures ------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: backpack | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Right now, `hs-boot` is used solely to support mutually recursive modules. However, as [wiki:Backpack Backpack] has shown, signatures are an essential part of separate modular development, and since hs-boot files are essentially module signatures, it would be good to move away from "hs- boot as a technical mechanism to make mutual recursion to work" to "hsig as a module signature useful for separate modular development and mutual recursion." Here are some of the things that this would entail: 1. Introduce hsig as a valid alternate file suffix to hs-boot (similarly have hisig for hi-boot; the plan being to eventually deprecate the hs-boot prefix) 2. Given an hsig file corresponding to a module in the current package database (but not from the currently being compiled package), check if the corresponding module implements the signature (this is the reverse of the current check we do for hs-boot files, which occurs when we typecheck the module, as opposed to the hs-boot file.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9252> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8172: Expose CWD and import search paths in GHCi via new `:show paths` command
by GHC 11 Jun '15

11 Jun '15

#8172: Expose CWD and import search paths in GHCi via new `:show paths` command -------------------------------------------+------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- - Currently, GHCi provides a `:cd` command but no respective builtin command to query the currently set path. - Moreover, there's no obvious way to query the currently active `importPaths` dynamic flags field, to find out which `-i` options are currently in effect. The attached patch extends `:show` with a `:show paths` subcommand, printing the CWD and the current value of `importPaths`: {{{ Ok, modules loaded: Main, InteractiveUI, Paths_ghci_ng, GhciMonad, GhciTags. λ> :show paths current working directory: /home/hvr/Haskell/My/ghci-ng module import search paths: dist/build/ghci-ng/ghci-ng-tmp ghc dist/build/autogen λ> :set -i λ> :show paths current working directory: /home/hvr/Haskell/My/ghci-ng module import search paths: none > :cd /tmp Warning: changing directory causes all loaded modules to be unloaded, because the search path has changed. > :show paths current working directory: /tmp module import search paths: none }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8172> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9101: Build 7.8.2 from sources on Windows/msys2
by GHC 09 Jun '15

09 Jun '15

#9101: Build 7.8.2 from sources on Windows/msys2 ------------------------------------+--------------------------------- Reporter: cchantep | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Hi, Trying to build GHC 7.8.2 from sources on Windows 7, from msys2 shell, required binaries such as gcc, ld, ar are forced to those in inplace directories (windows-extra), even system/env provide such tools (e.g. using pacman package manager in msys2): https://ghc.haskell.org/trac/ghc/browser/ghc/configure.ac#L274 . It leads to issues as tools in inplace are quite old. Particularly it can be critical about linking: GHC will be working with old ld, but you can have built/linked libraries using the more recent ld. Then, what's built using system tool can't be used throught GHC (ld version conflict). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9259: GHCi should list its available command line options
by GHC 08 Jun '15

08 Jun '15

#9259: GHCi should list its available command line options -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Driver | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- GHC can now list its command line options with `--show-options` (#7843). GHCi should be able to do the same. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9259> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8244: Removing the Cabal dependency
by GHC 06 Jun '15

06 Jun '15

#8244: Removing the Cabal dependency ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC depends on cabal, which is so far has been problematic many times, for many reasons. A few discussions include: * http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html * http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html GHC uses only a very small part of Cabal, in these files: {{{ ./compiler/ghci/Linker.lhs ./compiler/main/Packages.lhs ./compiler/main/PackageConfig.hs ./compiler/main/Finder.lhs }}} plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs (see http://www.haskell.org/pipermail/haskell-cafe/2013-September/108750.html for details). It was proposed that either * the package format could be a plain specification without direct code dependencies * the Cabal package could be split off into Cabal-the-build-system and a minimal part to describe the package DB to be shared by Cabal and GHC The Cabal part that is used is in only a few modules of Distribution.* while the remaining majority of the Cabal-the-library package is not used (e.g. none of Distribution.Simple.*). Decoupling GHC and Cabal seems to be a public desire, yet there are some problems with these approaches. Let us discuss them in this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #8723: sdist should not have to build everything
by GHC 04 Jun '15

04 Jun '15

#8723: sdist should not have to build everything ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It would be nice if instead of {{{ $ perl boot $ ./configure $ make $ make sdist }}} it would suffice to run {{{ $ perl boot $ ./configure $ make sdist }}} and if that would not build more than necessary to generate the tarballs. It would save time on the GHC-HEAD-Debian-Package-autobuilder that I am currently working on. I might look into this bug eventually, but if someone else feels like doing it: Even better. (Difficulty estimated conservatively; might well be less than an hour, besides maybe waiting for test runs to finish :-)) Remember to update MakingReleases and Building/StandardTargets if this is implemented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8292: linker_unload test doesn't work on Windows
by GHC 31 May '15

31 May '15

#8292: linker_unload test doesn't work on Windows ------------------------------------+---------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: linker_unload Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------------- I fixed up the major issues but I am getting: {{{ "/c/Users/ezyang/Dev/ghc-dyn/inplace/bin/ghc-stage2.exe" -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -c Test.hs -v0 # -rtsopts causes a warning "/c/Users/ezyang/Dev/ghc-dyn/inplace/bin/ghc-stage2.exe" -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db linker_unload.c -o linker_unload -no-hs-main -optc-Werror ./linker_unload \Users\ezyang\Dev\ghc-dyn\libraries\base\dist- install\build/libHSbase-4.7.0.0.a \Users\ezyang\Dev\ghc-dyn\libraries\ghc-prim\dist-install\build/libHSghc- prim-0.3.1.0.a \Users \ezyang\Dev\ghc-dyn\libraries\integer-gmp\dist-install\build/libHSinteger- gmp-0.5.1.0.a linker_unload.exe: \Users\ezyang\Dev\ghc-dyn\libraries\base\dist- install\build/libHSbase-4.7.0. 0.a: unknown symbol `_select' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8292> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6