May 2016 - ghc-tickets

[GHC] #11617: DYLD_LIBRARY_PATH ignored on Mac OS X 10.11.x
by GHC 07 Jul '16

07 Jul '16

#11617: DYLD_LIBRARY_PATH ignored on Mac OS X 10.11.x --------------------------------------+--------------------------------- Reporter: borsboom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- This was first reported on the Stack issue tracker at https://github.com/commercialhaskell/stack/issues/1161, but I've traced it to the fact that GHC uses shell script wrappers for many common commands, including `ghc`, `ghci`, and `hsc2hs`. Background: Mac OS X 10.11 introduced System Integrity Protection, which treats parts of the filesystem specially to prevent tampering with the system. Among those protections is that executables in `/bin`, such as `/bin/sh`, have the DYLD_LIBRARY_PATH variable stripped from the environment before being invoked. Since `ghc`, `hsc2hs`, and others are shell scripts that use `#!/bin/sh`, it means DYLD_LIBRARY_PATH is stripped from the environment when invoking them. I was able to work around this issue by copying `/bin/sh` to my home directory and then modifying the `#!` path in the `hsc2hs` to use the copy. I'm not sure what the best way to move forward is. Some possibilities I can think of: * Have installer tools for OS X (such as Stack, ghcformacosx, and Homebrew) apply the workaround themselves, although that leaves out anyone who installs directly from an official bindist or builds from source, and is a duplication of effort. * Have `make install` on OS X copy `/bin/sh` and "fix" the wrappers itself. * Replace the shell script wrappers with something written in Haskell that reads the paths from a configuration file. Note: I set the component to `hsc2hs` since that's where I encountered the problem, but I wouldn't be surprised if it also effected other cases (like `ghci`, and `ghc` with Template Haskell). I also hesitated to categorize this a "bug" since it's OS X's weird behaviour, and not actually something I feel GHC is doing wrong, causing this problem. But I doubt OS X is going to change, although it is possible (but not recommended) to disable SIP by booting into recovery mode and running `csrutil disable`, after which these protections are no longer in place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11617> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11727: Allow one type signature for multiple pattern synonyms
by GHC 01 Jul '16

01 Jul '16

#11727: Allow one type signature for multiple pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There's no reason why we shouldn't allow the same type signature for multiple pattern synonyms just like ordinary functions. For example, {{{ pattern A,B,C,D :: Int pattern A = 5 pattern B = 6 pattern C = 7 pattern D = 8 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11727> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12000: static pointer in ghci
by GHC 01 Jul '16

01 Jul '16

#12000: static pointer in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghci -fobject-code -ignore-dot-ghci -XStaticPointers GHCi, version 8.1.20160428: http://www.haskell.org/ghc/ :? for help Prelude> a = static id Prelude> a <interactive>:2:1: error: Variable not in scope: a Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12000> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11165: Testsuite framework failures are too easy to ignore and too hard to find
by GHC 01 Jul '16

01 Jul '16

#11165: Testsuite framework failures are too easy to ignore and too hard to find -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The testsuite driver really should do a better job of drawing the user's attention to framework failures. The only evidence in the testsuite summary that something went wrong is a non-zero "framework failures" count. If you notice that this count is non-zero then you need to sift manually through the initial log output produced by the driver and find the culprit. It's just generally terrible. Testsuite failures are failures, we should at least treat them as such and include them in the `TEST=...` message in the testsuite summary so they can be easily reproduced. Ideally we would also save the exception that caused the failure and show it in the summary as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11471: Note [The kind invariant] in TyCoRep needs to be updated
by GHC 28 Jun '16

28 Jun '16

#11471: Note [The kind invariant] in TyCoRep needs to be updated -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This Note, found in TyCoRep, needs to be updated to reflect `TypeInType`. It should not reference `OpenKind`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11471> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #9078: Segfault with makeStableName
by GHC 28 Jun '16

28 Jun '16

#9078: Segfault with makeStableName ------------------------------------+------------------------------------- Reporter: robertce | 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: | ------------------------------------+------------------------------------- Calling `makeStableName` on the same object many times causes a segfault. The following triggers this behaviour on both OSX and Linux-x86_64, provided it is compiled (it doesn't seem to occur if the call to `makeStableName` is interpreted). {{{ module Main where import Control.Monad import System.Mem.StableName main :: IO () main = replicateM_ 100000 (makeStableName foo) foo :: Int foo = 1 }}} It seems to happen largely at random. The 100000 calls to `makeStableName` in the above example essentially guarantee its occurrence, but I have observed it happen with far fewer. The reason this bug was discovered is it is causing frequent failures in Accelerate on 7.8.2. See [https://github.com/AccelerateHS/accelerate/issues/162] In that case it seems to be causing more `strange closure type` errors than segfaults, but I assume it is the same root cause. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9078> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #12112: Testsuite driver links from /tmp directory to .hi and .o files in source directory
by GHC 24 Jun '16

24 Jun '16

#12112: Testsuite driver links from /tmp directory to .hi and .o files in source directory -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11980 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a clear bug, but only shows up when the source directory is not clean. Perhaps from a validate run from before the `/tmp` testsuite patch. A user might also have been running some small sample programs in the source directory manually. The testsuite driver currently matches `<testname>*`. I'm not sure if a whitelist or blacklist solution is more future proof. These are all existing filetypes in the testsuite: {{{ $ find . -name tests | xargs dir | grep -v stderr | grep -v stdout Extension Files ==================================== .def (1) .tix (1) .hspp (2) .ghci (1) .primops (1) .mix (1) .gnp (2) .so (1) .md (2) .hx (1) .sh (1) .test (1) .cpp (2) .mm (1) .gitignore (7) .m (2) .asm (4) .conf (2) .h (19) .hsc (10) .lib (2) .pkg (14) .hs-boot (49) .txt (5) .hsig (14) .cabal (37) .gml (1) .cmm (46) .sample (14) .c (66) .dat (3) .pgn (1) .stdin (8) .lhs (23) .script (318) .plt (2) .T (311) (370) . (438) .hs (5343) Total: (10370) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11948: GHC forgets constraints
by GHC 23 Jun '16

23 Jun '16

#11948: GHC forgets constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Possibly related: #10338 The following program should compile, but fails with the error: {{{ Could not deduce (Bar (F zq) zq) arising from a use of ‘bar’ from the context (Bar (Foo (F zq)) (Foo zq)) bound by the type signature for bug :: Bar (Foo (F zq)) (Foo zq) => Foo (F zq) -> Foo zq }}} This is definitely incorrect: I am providing a `Bar` constraint in the context of `bug`, but GHC is asking for constraints so that it can resolve to the instance declared in Bar.hs. A few workarounds I've found so far, which may or may not help find the bug: 1. Adding `-XTypeFamilies` to Main.hs makes the program compile. 2. ''Removing'' the type signature from `x` in `bug` makes the program compile. 3. Defining `bug` without a `let` as `bug sk = bar sk :: Foo zq` or `bug sk = bar sk` makes the program compile. Main.hs: {{{ {-# LANGUAGE FlexibleContexts, ScopedTypeVariables #-} import Bar bug :: forall zq . (Bar (Foo (F zq)) (Foo zq)) => Foo (F zq) -> Foo zq bug sk = let x = bar sk :: Foo zq in x }}} Bar.hs {{{ {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} module Bar where type family F b newtype Foo r = Foo r type instance F (Foo r) = Foo (F r) class Bar a b where bar :: a -> b instance (Bar a b) => Bar (Foo a) (Foo b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11948> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10686: Process stops responding to sigINT
by GHC 22 Jun '16

22 Jun '16

#10686: Process stops responding to sigINT -------------------------------------+------------------------------------- Reporter: hamish | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Every now and then the leksah-server process has required a kill -9 it to get rid of it. Now Leksah is using the threaded RTS it seems to be happening in Leksah too. It is worse in Leksah because child processes inherit the behaviour and do not terminate when sent Leksah sends them sigINT (which Leksah does very frequently). Once the problem arrises it continues until the Leksah is restarted. Both leksah-server and Leksah start child processes using the process package. I think process package and the GHC GC both call blockUserSignals and it only has one place to store savedSignals. My guess is that two calls go into blockUserSignals from different threads before unblockUserSignals is called on either. The result is that when unblockUserSignals is called it does nothing (because savedSignals was overwritten). Perhaps savedSignals could use some kind of thread local storage? Also docs seem to indicate sigprocmask should not be used at all in multithreaded processes. Perhaps the GHC RTS should use pthread_sigprocmask instead? If the calling process delegates Ctrl+C the problem might be largely hidden. The sigINT signal is enabled again in the child fork and the parent will get an exception if the child is terminated with a sigINT. However I believe the parent is still left in a state where it will no longer respond to sigINT if the child process terminates normally (assuming two calls in a row were made to blockUserSignals at some point). The work around for now in Leksah is to reenable sigINT before each createProcess call. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10686> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11081: Implement Introspective Template Haskell
by GHC 22 Jun '16

22 Jun '16

#11081: Implement Introspective Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: ⊥ Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: | TemplateHaskell/Introspective -------------------------------------+------------------------------------- This ticket is to track commentary and reactions to TemplateHaskell/Introspective, and to help the proposal not get lost. Contrary to the title of this ticket, it is not yet resolved that Introspective Template Haskell should ever be implemented. But with some of the support that it's gotten, it seemed appropriate to make a ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9