September 2015 - ghc-tickets

[GHC] #10633: GHCi segfaults on arm
by GHC 07 Nov '15

07 Nov '15

#10633: GHCi segfaults on arm ---------------------------------+------------------------------- Reporter: Thra11 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------+------------------------------- I define a data type: {{{#!hs data Tree a = Leaf a | Tree { left :: Tree a , right :: Tree a } deriving Show }}} Then I create a few named trees: {{{#!hs testTree0 = Leaf 0 testTree1 = Tree (Leaf 0) (Leaf 0) testTree2 = Tree testTree0 testTree0 testTree3 = Tree testTree1 testTree1 testTree4 = Tree (Tree (Leaf 0) (Leaf 0)) (Tree (Leaf 0) (Leaf 0)) }}} This segfaults in GHCi (works fine with non-interactive GHC): {{{#!hs main = print testTree3 }}} == Notes == * testTree3 and testTree4 represent the same tree, constructed in different ways. However, testTree3 segfaults when it tries to print the second testTree1; testTree4 does not. * entering 'print testTree1' twice segfaults, but only if it is twice in a row. * strangely enough, printing testTree4 repeatedly does not segfault. * printing testTree0 many times in a row doesn't segfault either. * printing testTree2 segfaults. It seems to be something to do with repetition or reevaluation of the same named structure. I haven't yet managed to determine whether the print is relevant or whether it's forcing the evaluation of the data structure that causes the segfault (Can't remember how to force a list but discard the result). I have attached the the output from running ghci with +RTS -Di. Let me know if there's anything else I should try. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9591: Add custom "Wiki" field in Trac
by GHC 06 Nov '15

06 Nov '15

#9591: Add custom "Wiki" field in Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I want to request a new custom field to Trac called "Wiki page"? Tickets that are about implementing a larger feature have an accompanying wiki page that summarizes the design. It would help my workflow if I could just get to that wiki page from the top of a Trac ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9591> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10435: catastrophic exception-handling disablement on Windows Server 2008 R2
by GHC 04 Nov '15

04 Nov '15

#10435: catastrophic exception-handling disablement on Windows Server 2008 R2 -------------------------------------+------------------------------------- Reporter: malcolmw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Windows Keywords: windows, | Type of failure: Runtime crash exceptions | Blocked By: Architecture: x86 | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- We have found a very strange RTS bug that only manifests on some Windows machines, running Windows Server 2008 R2. It does not occur on our Windows 7 machines. We are not sure whether the installed version of Visual C runtime system matters. The context is a ghc-compiled executable, that calls a function from a C++ DLL. The C++ function throws an exception internally, then catches it, and returns normally. The symptom of the bug is that, from ghc-7.8.1 onwards, including ghc-7.10.1, the C++ exception is not caught by the C++ code, but terminates the program catastrophically, with exit code 127. When the Haskell executable is compiled by ghc-7.2.3 or before, the bug does not happen. If, instead of having the main function in Haskell, we write a wrapper main function in C++, that calls the Haskell from a DLL (and the Haskell then calls back into C++), the bug does not happen. Hence, we surmise there is some ghc RTS initialisation that is specific to Windows, that deals with exception handling, and that is incorrect for certain versions of Windows. Attached to the ticket, please find (a) a C++ module, which exports a single function that throws an exception and catches it; (b) a Haskell module which imports the C++ via the FFI, and calls it; (c) a build script which compiles the C++ to a DLL, using the MSVC compiler, compiles the Haskell with ghc, and links them together. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10435> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10736: threadWaitRead/registerFd unusable
by GHC 03 Nov '15

03 Nov '15

#10736: threadWaitRead/registerFd unusable -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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 Revisions: | -------------------------------------+------------------------------------- The following program: {{{ module Main where import System.Posix.IO import GHC.Event main = do Just mgr <- getSystemEventManager fd <- openFd "/tmp/bleh" ReadOnly Nothing defaultFileFlags { nonBlock = True } key <- registerFd mgr (\_ _ -> putStrLn "hello") fd evtRead MultiShot return () }}} fails with: {{{ *** Exception: modifyFdOnce: permission denied (Operation not permitted) }}} Since `threadWaitRead` and family are implemented in terms of `registerFd`, they also fail with the same error. Perhaps I am misunderstanding how to use this function, but in this case the conditions that must hold true regarding file descriptors should be documented somewhere. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10848: GHC/GHCi should optionally print errors in reversed order
by GHC 03 Nov '15

03 Nov '15

#10848: GHC/GHCi should optionally print errors in reversed order -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: GHCi | Version: 7.11 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This would be super useful especially when refactoring. The way I usually do refactoring is that I break things with a change, and then reload GHCi, fixing a couple of errors at a time. I almost always start with first error, which means I have to scroll every time I reaload GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes)
by GHC 01 Nov '15

01 Nov '15

#10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: #10682 Differential Revisions: | -------------------------------------+------------------------------------- Attempting to build GHC on an x86_64 Linux machine fails for me: {{{ $ make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations ApiAnnotation Avail Bag BasicTypes Binary BooleanFormula BreakArray BufWrite Class CmdLineParser CmmType CoAxiom ConLike Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CoreSeq CoreStats CostCentre Ctype DataCon Demand Digraph DriverPhases DynFlags Encoding ErrUtils Exception FamInstEnv FastFunctions FastMutInt FastString Fingerprint FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit PlaceHolder HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceSyn IfaceType InstEnv Kind Lexeme Lexer ListSetOps Literal Maybes MkCore MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCore PrelNames PrelRules Pretty PrimOp RdrName Rules Serialized SrcLoc StaticFlags StringBuffer TcEvidence TcRnTypes TcType TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmSwitch CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.ARM64 CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream" dll-split: out of memory (requested 1099512676352 bytes) make[1]: *** [compiler/stage2/dll-split.stamp] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10877> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10917: Provide a utility to check API Annotations
by GHC 01 Nov '15

01 Nov '15

#10917: Provide a utility to check API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- At the moment it is difficult for GHC developers to know if they have broken the API Annotations. Provide a utility that can be used as a test to show up errors in the API Annotations. This is to be based on the current tests for ghc-api/annotations which can parse a file using the just-built GHC API, and check that no annotations are disconnected from the ParsedSource in the output. In addition, it should be able to dump the annotations to a file, so a new feature developer can check that all changes to the parser do provide annotations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10917> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10890: Incorrect redundant import warning for type classes
by GHC 30 Oct '15

30 Oct '15

#10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | 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 Revisions: | -------------------------------------+------------------------------------- Given the three files below, the import marked with (!!!) is reported as redundant. Upon deleting it, GHC reports that "has" is not a visible class method of BClass. This came up in the context of the MFP (#10751), with the correspondences Base<->Control.Monad, Extends<->Control.Monad.Fail. We would like to have Control.Monad re-export Control.Monad.Fail.MonadFail without its (clashing) member "fail" for the time being. For future compatibility, some modules should implement MonadFail right now, requiring us to import Control.Monad.Fail explicitly in order to write an instance. Said procedure leads to the described import warning, which breaks the validation script for example. {{{#!hs -- Base.hs module Base (AClass(..), BClass()) where import Extends (BClass()) class AClass a where has :: a }}} {{{#!hs -- Extends.hs module Extends where class BClass b where has :: b }}} {{{#!hs -- UseSite.hs module UseSite where import Base import Extends -- (!!!) data Bar = Bar instance AClass Bar where has = Bar instance BClass Bar where has = Bar }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10370: Compile time regression in OpenGLRaw
by GHC 26 Oct '15

26 Oct '15

#10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- As reported by Paolo Veronelli: Hello, I'm using ghc 7.10.1 to compile OpenGLRaw which is now impossible with -O1 and -O2 due to "ghc : out of memory error" on a 4GB linux host. The file making memory explode is Graphics.Rendering.OpenGL.Raw.Functions. With -O0 it uses 600 MB. The file is really huge, but I could compile it with prior versions of ghc. I've had a look and indeed the file takes way more memory to compile with HEAD. Looking at the heap profiles, it seems that the problem is in GHC itself (space leak somewhere?). I'll attach the heap profiles (from compiling the single module itself, i.e., `touch`ing the file and running prof GHC on it). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10242: Multiple constraint wildcards allowed with PartialTypeSignatures
by GHC 22 Oct '15

22 Oct '15

#10242: Multiple constraint wildcards allowed with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple PartialTypeSignatures | Type of failure: GHC accepts Architecture: | invalid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The [https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures wiki] states that > As a single extra-constraints wildcard is enough to infer any number of constraints, only one is allowed in a type signature and it should come last in the list of constraints. However the following program compiles with GHC 7.10.1 {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} f :: (Eq a, _, _) => a -> a -> Bool f x y = x == y }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10242> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7