May 2018 - ghc-tickets

[GHC] #12607: Memory effects in doomed STM transactions
by GHC 07 Aug '18

07 Aug '18

#12607: Memory effects in doomed STM transactions -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: STM, allocate | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- == Problem == GHC's STM implementation does "lazy" validation meaning that speculative execution can continue even after observing an inconsistent view of memory. Transactions in the state are called "doomed transactions". While the runtime tries to avoids some effects in doomed transactions, such as entering an infinite loop, it does not successfully control all memory effects. In particular there are many (I do not have an exhaustive list) allocations that eventually end up in the `allocate` function which is nicely documented with the following: > `allocate()` never > fails; if it returns, the returned value is a valid address. If > the nursery is already full, then another block is allocated from > the global block pool. If we need to get memory from the OS and > that operation fails, then the whole process will be killed. https://github.com/ghc/ghc/blob/master/rts/sm/Storage.c#L819 A doomed transaction that demands a large allocation that the OS cannot fulfill will kill the process. Here is a program that reliably fails for me: {{{#!hs -- oom.hs {-# LANGUAGE BangPatterns #-} import GHC.Conc import Control.Concurrent import qualified Data.ByteString as B forever act = act >> forever act check True = return () check False = retry main = do tx <- newTVarIO 0 ty <- newTVarIO 1 tz <- newTVarIO 0 done <- newTVarIO False _ <- forkIO $ forever $ atomically $ do -- Only read tx and ty x <- readTVar tx y <- readTVar ty if x > y -- This should always be False then do -- We only get here in a doomed transaction. Commenting out the next two lines -- but leaving the write to done and the program runs as expected because the -- doomed transaction is detected at commit time. let !big = B.length $ B.replicate maxBound 0 -- The big allocation! writeTVar tz big writeTVar done True else return () let mut = forever $ atomically $ do y <- readTVar ty x <- readTVar tx if x > 1000 then do -- When we get big enough, start over. writeTVar tx 0 writeTVar ty 1 -- Always holds semantically that tx < ty else do -- increment x and y both writeTVar ty (succ y) writeTVar tx (succ x) -- tx < ty -- Give lots of opportunities to witness inconsistent memory. _ <- forkIO mut _ <- forkIO mut _ <- forkIO mut atomically $ readTVar done >>= check putStrLn "Done" }}} Running leads to out of memory: {{{#!bash > ghc oom.hs -fno-omit-yields -threaded [1 of 1] Compiling Main ( oom.hs, oom.o ) Linking oom.exe ... > ./oom.exe +RTS -N oom.exe: out of memory }}} == Fixing == When a potentially bad memory effect is about to happen in some thread, we need to ensure that we validate any running transaction and if it fails have some way to back out of the operation and abort the transaction. This might be tricky on two fronts 1) finding all the critical allocations and 2) finding places where we can both detect (1) and abort the transaction. The places I'm concerned about most are array allocation such as the `ByteString` in the example and maybe `Integer` allocation. Another fix is a different STM implementation altogether that (at a performance cost or trade-off) doesn't allow doomed transactions (to appear Haskell Symposium 2016 :D). I think we can at least address this particular example without going so far. A related issue is more general memory leaks from doomed transactions. Consider a program with a memoized Fibonacci function. The semantics of the transactions written by the programmer may ensure that no value higher then 10 is ever demanded of that function, yet in a doomed transaction the invariant goes wrong and the program demands 100. The program will detect the doomed transaction eventually in this case, but not before it has allocated a large live blob never to be touched again. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12607> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15064: T8089 mysteriously fails when GHC is built with LLVM
by GHC 06 Aug '18

06 Aug '18

#15064: T8089 mysteriously fails when GHC is built with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (LLVM) | 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: -------------------------------------+------------------------------------- CircleCI's LLVM build revealed that `T8089` fails. The test is quite simple, {{{#!hs main = threadDelay maxBound }}} and is expected to timeout. However, it somehow exits with code 0 in all ways when built with LLVM. This didn't reproduce when I tried `make test TEST=T8089 EXTRA_HC_OPTS=-fllvm` locally, so either it's a library issue or environment-sensitive. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12625: Bad error message for flags with required but missing arguments
by GHC 06 Aug '18

06 Aug '18

#12625: Bad error message for flags with required but missing arguments -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- {{{ $ ghc -I ghc: unrecognised flag: -I did you mean one of: -I -F -v Usage: For basic information, try the `--help' option. }}} Which is confusing (Unrecognized `-I`. Did you mean `-I`?), and not informative (No mention of the missing argument) I expect something like "missing argument for `-I`", or a basic usage info on `-I` instead. It looks similar to #9776 to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12625> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file
by GHC 06 Aug '18

06 Aug '18

#13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #13137, #9868, | #10355 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For ghc 8.0.2 (on Linux, in nixpkgs `0c041520c3` for exact reproducibility), when TH is used in a `ghc --make -j1` invocation, and thus ghc does the whole {{{ cc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-std=c++14' -Wno- deprecated-declarations --print-file-name liblibglog.so Loading object (dynamic) glog ... done }}} business, and the `.so` file in question does not exist, then usually GHC prints {{{ <command line>: user specified .o/.so/.DLL could not be loaded (libglog.so: cannot open shared object file: No such file or directory) }}} However, I found that when parallel compilation is enabled, (e.g. `ghc -j4`), I can get this instead: {{{ [ 23 of 130] Compiling Mymodule ( Mymodule.hs, dist/build/Mymodule.o ) <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13531> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13368: Derive superclasses automatically if possible
by GHC 05 Aug '18

05 Aug '18

#13368: Derive superclasses automatically if possible -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10607 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- So I don't forget, this is like #10607 along another axis. Instead of writing {{{#!hs newtype IO_ a = IO_ (IO a) deriving newtype (Functor, Applicative, Monad, MonadIO) }}} allow writing {{{#!hs newtype IO_ a = IO_ (IO a) deriving newtype MonadIO }}} with the same meaning, are there any technical restrictions to this? This gets annoying in large hierarchies where you need `Eq`, `Ord`, `Num`, `Fractional`, `Floating`, `Real` and `RealFrac` just to derive {{{#!hs newtype F32 = F32 Float deriving newtype RealFloat }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13368> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds
by GHC 03 Aug '18

03 Aug '18

#13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- `lol-0.6.0.0` from Hackage currently fails to build with GHC 8.2.1 because of this regression. Here is a minimized example: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE MonoLocalBinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Crypto.Lol.Types.FiniteField (GF(..)) where import Data.Functor.Identity (Identity(..)) data T a type Polynomial a = T a newtype GF fp d = GF (Polynomial fp) type CRTInfo r = (Int -> r, r) type Tagged s b = TaggedT s Identity b newtype TaggedT s m b = TagT { untagT :: m b } class Reflects a i where value :: Tagged a i class CRTrans mon r where crtInfo :: Reflects m Int => TaggedT m mon (CRTInfo r) instance CRTrans Maybe (GF fp d) where crtInfo :: forall m . (Reflects m Int) => TaggedT m Maybe (CRTInfo (GF fp d)) crtInfo = undefined }}} This typechecks OK with GHC 8.0.2, but with 8.2.1, it complains: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170403: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Crypto.Lol.Types.FiniteField ( Bug.hs, interpreted ) Bug.hs:25:14: error: • Couldn't match type ‘k0’ with ‘k2’ because type variable ‘k2’ would escape its scope This (rigid, skolem) type variable is bound by the type signature for: crtInfo :: forall k2 (m :: k2). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) at Bug.hs:25:14-79 Expected type: TaggedT m Maybe (CRTInfo (GF fp d)) Actual type: TaggedT m Maybe (CRTInfo (GF fp d)) • When checking that instance signature for ‘crtInfo’ is more general than its signature in the class Instance sig: forall (m :: k0). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) Class sig: forall k2 (m :: k2). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) In the instance declaration for ‘CRTrans Maybe (GF fp d)’ | 25 | crtInfo :: forall m . (Reflects m Int) => TaggedT m Maybe (CRTInfo (GF fp d)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:25:14: error: • Could not deduce (Reflects m Int) from the context: Reflects m Int bound by the type signature for: crtInfo :: forall k2 (m :: k2). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) at Bug.hs:25:14-79 The type variable ‘k0’ is ambiguous • When checking that instance signature for ‘crtInfo’ is more general than its signature in the class Instance sig: forall (m :: k0). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) Class sig: forall k2 (m :: k2). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) In the instance declaration for ‘CRTrans Maybe (GF fp d)’ | 25 | crtInfo :: forall m . (Reflects m Int) => TaggedT m Maybe (CRTInfo (GF fp d)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Notably, both `PolyKinds` and `MonoLocalBinds` are required to trigger this bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13555> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15141: decideKindGeneralisationPlan is too complicated
by GHC 02 Aug '18

02 Aug '18

#15141: decideKindGeneralisationPlan is too complicated -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider this program, which originally comes from #14846. I have decorated it with kind signatures so you can see what is going on {{{ {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module T14846 where import Data.Kind import Data.Proxy -- Cat :: * -> * type Cat ob = ob -> ob -> Type -- Struct :: forall k. (k -> Constraint) -> * data Struct :: (k -> Constraint) -> Type where S :: Proxy (a::k) -> Struct (cls::k -> Constraint) -- Structured :: forall k -- forall (a:k) (cls:k->Constraint) -> Struct k cls type Structured a cls = (S ('Proxy :: Proxy a) :: Struct cls) -- AStruct :: forall k (cls : k->Constraint). Struct cls -> Type data AStruct :: Struct cls -> Type where AStruct :: cls a => AStruct (Structured a cls) -- StructI :: forall k1 k2 (cls :: k2 -> Constraint). -- k1 -> Struct k2 cls -> Constraint class StructI xx (structured::Struct (cls :: k -> Constraint)) where struct :: AStruct structured -- Hom :: forall k1 k2 (cls :: k2 -> Constraint). -- Cat k1 -> Cat (Struct {k2} cls) data Hom :: Cat k -> Cat (Struct cls) where -- Category :: forall ob. Cat ob -> Constraint class Category (cat::Cat ob) where i :: StructI xx a => ríki a a instance forall (riki :: Cat kx) (cls :: kk -> Constraint). Category riki => Category (Hom riki :: Cat (Struct cls)) where i :: forall xx a. StructI xx a => Hom riki a a i = case struct :: AStruct (Structured a cls) of }}} Focus on the final instance declaration. Do kind inference on the type signature for `i`. I think we should get {{{ i :: forall {k1} {k2} {cls1 :: k2 -> Constraint} forall (xx :: k1) (a :: Struct {k2} cls1). StructI {k1} {k2} xx a => Hom {kx} {k2} riki a a }}} Nothing about `i`'s type signature constraints the `cls` to be the same as the in-scope `cls`. Yes `riki` is in scope, but its kind is unrelated. But at present GHC does not kind-generalise `i`'s type (because of `kindGeneralisationPlan`), so random things in the body of `i` may influence how its kinds get fixed. And if we changed the signature a bit so that it didn't mention `riki` any more, suddenly it ''would'' be kind-generalised. This seems incomprehensibly complicated to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15141> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10087: DefaultSignatures: error message mentions internal name
by GHC 02 Aug '18

02 Aug '18

#10087: DefaultSignatures: error message mentions internal name -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: feature | Milestone: request | Version: 7.8.4 Priority: normal | Operating System: Unknown/Multiple Component: Compiler | Type of failure: Other (Type checker) | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DefaultSignatures #-} class C a where reflexive :: a -> Bool default reflexive :: Eq a => a -> Bool reflexive x = x == x data D instance C D where -- /home/abel/play/haskell/bugs/DefaultSig.hs:10:10: -- No instance for (Eq D) arising from a use of ‘Main.$gdmreflexive’ -- In the expression: Main.$gdmreflexive -- In an equation for ‘reflexive’: reflexive = Main.$gdmreflexive -- In the instance declaration for ‘C D’ }}} Error looks odd: The user has not written $gdmreflexive in his code. TODO: Better error message. Maybe this should just trigger a warning that method {{{reflexive}}} is undefined for instance {{{D}}} of {{{C}}}. Like when I remove the default method. {{{ /home/abel/play/haskell/bugs/DefaultSig.hs:10:10: Warning: No explicit implementation for ‘reflexive’ In the instance declaration for ‘C D’ }}} It seems the semantics of a default signature is that each instance *must* implement this method. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12096: Attach stacktrace information to SomeException
by GHC 02 Aug '18

02 Aug '18

#12096: Attach stacktrace information to SomeException -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Now (base 4.9.0.0) ErrorCall contain field for stacktrace information and error fills it. If you add field for stacktrace information to SomeException {{{#!hs data SomeException where SomeExceptionWithLocation :: Exception e => String -> e -> SomeException pattern SomeException :: () => Exception e => e -> SomeException pattern SomeException err <- SomeExceptionWithLocation _ err where SomeException err = SomeExceptionWithLocation "" err }}} and will fills it in throw {{{#!hs throw :: (HasCallStack, Exception e) => e -> a throw e = unsafeDupablePerformIO $ do stack <- currentCallStack raise# (CallStackException e $ if stack /= [] then prettyCallStack ?callStack ++ "\n" ++ renderStack stack else prettyCallStack ?callStack) }}} it will be more useful for ghci users. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #11759: can't decompose ghc.exe path
by GHC 02 Aug '18

02 Aug '18

#11759: can't decompose ghc.exe path --------------------------------------+---------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- {{{ erisco@ERICWIN C:\Users\erisco\haskell-platform-bin $ ghc.exe ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): can't decompose ghc.exe path: "C:\\Users\\erisco\\haskell- platform-bin\\ghc.exe" }}} haskell-platform-bin is a symbolic directory link to "C:\Program Files\Haskell Platform\2014.2.0.0\bin". I did this so there would not be spaces in the path because this is causing other issues for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10