- ghc-tickets - Haskell.org

[GHC] #15892: Segmentation fault with ByteString and -O
by GHC 22 Nov '18

22 Nov '18

#15892: Segmentation fault with ByteString and -O --------------------------------------+---------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- The attached program consistently segfaults (within a few seconds) when compiled with ghc-8.6.1 or ghc-8.6.2. It runs forever (as expected) when compiled with ghc-8.4. To reproduce: {{{ ghc segfault.hs }}} then, {{{ ./segfault >/dev/null }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15892> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #15633: Type-checker plugins aren't loaded in 8.6.1
by GHC 22 Nov '18

22 Nov '18

#15633: Type-checker plugins aren't loaded in 8.6.1 -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 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: -------------------------------------+------------------------------------- Type-Checker plugins seem to work in GHCi-8.4.3 https://gist.github.com/phadej/f2040eba327a88d3652cda021403f97f However with GHC-8.6.1 The Glorious Glasgow Haskell Compilation System, version 8.6.0.20180907 76a233143f1ec940f342ce3ce3afaf306923b392 (which seems to be the last commit in 8.6 branch atm) the plugins aren't loaded. {{{ % ghci-8.6.1 -fplugin=ThereIsNoPlugin GHCi, version 8.6.0.20180907: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ogre/.ghci λ> }}} starts a session without a warning. 8.4.3 however fails: {{{ % ghci-8.4.3 -fplugin=ThereIsNoPlugin GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help <command line>: Could not find module ‘ThereIsNoPlugin’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15906: Stable name allocation causes heap corruption when GC is triggered in the primop
by GHC 22 Nov '18

22 Nov '18

#15906: Stable name allocation causes heap corruption when GC is triggered in the primop -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Runtime | Version: 8.7 System | 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 error is originally reported in #15241, and is caught by the test `memo001` when run with `-debug` (which only happens in sanity way currently). Here's the problem. mkStableName# is defined like this: {{{ stg_makeStableNamezh ( P_ obj ) { W_ index, sn_obj; (index) = ccall lookupStableName(obj "ptr"); /* Is there already a StableName for this heap object? * stable_name_table is a pointer to an array of snEntry structs. */ if ( snEntry_sn_obj(W_[stable_name_table] + index*SIZEOF_snEntry) == NULL ) { ALLOC_PRIM (SIZEOF_StgStableName); <------------ PROBLEM HERE ---------- sn_obj = Hp - SIZEOF_StgStableName + WDS(1); SET_HDR(sn_obj, stg_STABLE_NAME_info, CCCS); StgStableName_sn(sn_obj) = index; snEntry_sn_obj(W_[stable_name_table] + index*SIZEOF_snEntry) = sn_obj; } else { sn_obj = snEntry_sn_obj(W_[stable_name_table] + index*SIZEOF_snEntry); } return (sn_obj); } }}} There's a problem in the annotated line: if we allocate a `snEntry` in the stable name table, but run out of heap to actually allocate the `StgStableName` we call GC with incorrect `snEntry` contents. As a reminder, this is `snEntry`: {{{ typedef struct { StgPtr addr; // Haskell object when entry is in use, next free // entry (NULL when this is the last free entry) // otherwise. May be NULL temporarily during GC (when // pointee dies). StgPtr old; // Old Haskell object, used during GC StgClosure *sn_obj; // The StableName object, or NULL when the entry is // free } snEntry; }}} In summary, `sn_obj == NULL` means the entry is free. When we trigger the GC after allocating the `snEntry` but before allocating the `StgStableName`, we end up calling the GC with `sn_obj == NULL` even though the `snEntry` is not actually free. In particular, the `addr` field should be updated by `gcStableNameTable`, but it's currently not because `gcStableNameTable` sees `sn_obj` as NULL and skips the entry. The is caught by memo001 when run with -debug. I already have a fix and will submit a patch soon. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15906> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15796: Core Lint error
by GHC 22 Nov '18

22 Nov '18

#15796: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- This gives a Core Lint error {{{#!hs {-# Language QuantifiedConstraints #-} {-# Language TypeApplications #-} {-# Language TypeOperators #-} {-# Language PolyKinds #-} {-# Language FlexibleInstances #-} {-# Language DataKinds #-} {-# Language TypeFamilies #-} {-# Language MultiParamTypeClasses #-} {-# Language ConstraintKinds #-} {-# Language UndecidableInstances #-} {-# Language GADTs #-} {-# Options_GHC -dcore-lint #-} import Data.Kind type Cat ob = ob -> ob -> Type class Ríki (obj :: Type) where type (-->) :: Cat obj class Varpi (f :: dom -> cod) newtype (··>) :: Cat (a -> b) where Natu :: Varpi f => (forall xx. f xx --> f' xx) -> (f ··> f') instance Ríki cod => ------------- Ríki (dom -> cod) where type (-->) = (··>) @dom @cod }}} {{{ $ ghci -ignore-dot-ghci 568_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 568_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): Core Lint error <no location info>: warning: In the type ‘(··>)’ Found TcTyCon: ··>[tc] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/FamInst.hs:171:31 in ghc:FamInst Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :q Leaving GHCi. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15787: GHC panic using kind application
by GHC 22 Nov '18

22 Nov '18

#15787: GHC panic using kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using GHC head at diff [https://phabricator.haskell.org/D5229 Visible kind application D5229] (#12045), bug goes away if you remove `@ob`. {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language DataKinds #-} {-# Language PolyKinds #-} {-# Language GADTs #-} {-# Language TypeFamilies #-} import Data.Kind class Ríki (ob :: Type) where type Hom :: ob -> ob -> Type data Kl_kind :: forall ob . (ob -> ob) -> ob -> Type where Kl :: k -> Kl_kind @ob (m) k type family UnKl (kl :: Kl_kind m k) = (res :: k) where UnKl (Kl a) = a }}} {{{ $ ghci -ignore-dot-ghci 543_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 543_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_a1yH} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15787> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #5211: Missing warning about redundant import for a class instance
by GHC 22 Nov '18

22 Nov '18

#5211: Missing warning about redundant import for a class instance ---------------------------------+----------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Type of failure: None/Unknown | Test Case: rename/should_fail/T5211 Blocked By: | Blocking: ---------------------------------+----------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"6353efc7694ba8ec86c091918e02595662169ae2/ghc" 6353efc7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6353efc7694ba8ec86c091918e02595662169ae2" Fix unused-import warnings This patch fixes a fairly long-standing bug (dating back to 2015) in RdrName.bestImport, namely commit 9376249b6b78610db055a10d05f6592d6bbbea2f Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Wed Oct 28 17:16:55 2015 +0000 Fix unused-import stuff in a better way In that patch got the sense of the comparison back to front, and thereby failed to implement the unused-import rules described in Note [Choosing the best import declaration] in RdrName This led to Trac #13064 and #15393 Fixing this bug revealed a bunch of unused imports in libraries; the ones in the GHC repo are part of this commit. The two important changes are * Fix the bug in bestImport * Modified the rules by adding (a) in Note [Choosing the best import declaration] in RdrName Reason: the previosu rules made Trac #5211 go bad again. And the new rule (a) makes sense to me. In unravalling this I also ended up doing a few other things * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the things that are used, rather than [AvailInfo]. This is simpler and more direct. * Rename greParentName to greParent_maybe, to follow GHC naming conventions * Delete dead code RdrName.greUsedRdrName Bumps a few submodules. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27 Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5312 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5211#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14784: RTS header files can't be used with a C++ compiler
by GHC 22 Nov '18

22 Nov '18

#14784: RTS header files can't be used with a C++ compiler -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: System | 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: -------------------------------------+------------------------------------- If you compile `m1.cpp`: {{{ #include "Rts.h" int main(int argc, char** argv) { } }}} with: {{{ g++ -g m1.cpp -std=c++11 -I includes/ -c }}} you get: {{{ In file included from includes/Rts.h:29:0, from m1.cpp:1: includes/Stg.h:29:3: error: #error __STDC_VERSION__ does not advertise C99 or later # error __STDC_VERSION__ does not advertise C99 or later ^ }}} It's not advertised anywhere that it should work, but it used to work. https://phabricator.haskell.org/D2045 is what introduced this check. Judging by https://stackoverflow.com/questions/48045243/ghc-gcc-compiler- issue-stdc-version-w-c99-from-stg-h-fails-for-every-packa, it affects GHC 8.2 and later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14784> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15669: T7040_ghci has a suspicious testcase failure
by GHC 22 Nov '18

22 Nov '18

#15669: T7040_ghci has a suspicious testcase failure ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: T7040_ghci | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- T7040_ghci has a weird failure. This looks like BSS initialization issue in the linker maybe? {{{ +++ rts/T7040_ghci.run/T7040_ghci.run.stdout.normalised 2018-09-23 17:26:01.197146900 +0100 @@ -1,2 +1,2 @@ -x: 0 +x: 493156 x: 1 }}} Luckily the value seems to mutate correctly. So it may just be a simple missing `memset`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15669> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15871: Revamp -fprint-explicit-kinds
by GHC 22 Nov '18

22 Nov '18

#15871: Revamp -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- With the imminent #12045, we will have type application in kinds. This ticket tracks mirroring this new behavior in the pretty-printer. To wit, when `-fprint-explicit-kinds` is enabled, we should 1. Print instantiations of specified variables like `@...`. 2. Print instantiations of inferred variables like `@{...}`. Examples: {{{#!hs data Proxy (a :: k) = Proxy -- Then, `Proxy Int` would be printed as `Proxy @Type Int` with -fprint- explicit-kinds data Proxy2 a = Proxy2 -- Then, `Proxy2 Int` would be printed as `Proxy2 @{Type} Int` with -fprint-explicit-kinds }}} In addition, sometimes error messages suggest enabling `-fprint-explicit- kinds`. Instead of doing this, we should just locally enable the flag. The existence of the `@` prefixes will alert the reader that these are not type arguments. (Without the `@` syntax, locally and silently enabling `-fprint-explicit-kinds` would be very confusing.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15871> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15852: Bad axiom produced for polykinded data family
by GHC 22 Nov '18

22 Nov '18

#15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: TypeFamilies, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I say {{{#!hs data family DF a (b :: k) data instance DF (Proxy c) :: Proxy j -> Type }}} with `-ddump-tc`, I get {{{ axiom Scratch.D:R:DFProxyProxy0 :: forall k1 k2 (c :: k1) (j :: k2) (a :: Proxy j). DF (Proxy c) a = Scratch.R:DFProxyProxy k1 k2 c j }}} This is bogus, because `a` should be on the RHS, too. It's not clear to me whether this is a pretty-printing bug or a real one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15852> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8