- ghc-tickets - Haskell.org

[GHC] #9868: ghc: panic! Dynamic linker not initialised
by GHC 07 Aug '18

07 Aug '18

#9868: ghc: panic! Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: Jamedjo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I was playing around and not expecting cabal build to succeed yet. If if didn't say the impossible had happened I would assumed I was missing something and used the error to drive my next action {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} There had been another error before: {{{ <no location info>: <command line>: can't load .so/.DLL for: /Users/JamesEJ/bindings- cef3/dist/build/libHSbindings-cef3-0.1.0-ghc7.8.3.dylib (dlopen(/Users/JamesEJ/bindings-cef3/dist/build/libHSbindings- cef3-0.1.0-ghc7.8.3.dylib, 9): Symbol not found: _cef_add_cross_origin_whitelist_entry Referenced from: /Users/JamesEJ/bindings-cef3/dist/build/libHSbindings- cef3-0.1.0-ghc7.8.3.dylib Expected in: flat namespace in /Users/JamesEJ/bindings-cef3/dist/build/libHSbindings- cef3-0.1.0-ghc7.8.3.dylib) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9868> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[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] Batch modify: #15227, #15363, #15375, #15452
by GHC 06 Aug '18

06 Aug '18

Batch modification to #15227, #15363, #15375, #15452 by bgamari: milestone to 8.8.1 Comment: These won't be fixed in GHC 8.6 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=15227%2C15363%2C15375%2C15452> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #11295, #13724, #14164, #14401, #14405, #14412, ...
by GHC 06 Aug '18

06 Aug '18

Batch modification to #11295, #13724, #14164, #14401, #14405, #14412, #15053, #15075, #15159, #15213, #15241, #15298, #15309, #15312, #15313, #15319, #15320, #15322, #15325, #15326, #15327, #15328, #15332, #15336, #15337, #15338, #15340, #15344, #15345, #15354, #15356, #15359, #15360, #15361, #15362, #15368, #15369, #15376, #15377, #15378, #15379, #15381, #15382, #15383, #15384, #15388, #15389, #15391, #15392, #15394, #15395, #15403, #15404, #15409, #15411, #15414, #15416, #15420, #15424, #15426, #15427, #15433, #15434, #15435, #15437, #15443, #15448, #15449, #15454, #15459, #15460, #15461, #15464, #15470, #15471, #15477, #15478, #15483, #15484 by bgamari: milestone to 8.8.1 Action: leave Comment: These won't be fixed for in GHC 8.6. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=11295%2C13724%2C14164%2C14401%2C14…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15465: PAP object entered
by GHC 06 Aug '18

06 Aug '18

#15465: PAP object entered ---------------------------------------+---------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: ---------------------------------------+---------------------------------- This occurred while running our sizeable program I have no idea what the program was doing when this error was encountered but the compiler asked me to report it here: programName: internal error: PAP object entered! (GHC version 8.4.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted I don't have a way to reproduce this yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15465> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails)
by GHC 06 Aug '18

06 Aug '18

#15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypedHoles | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program panics on GHC 8.6 and HEAD: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Type.Equality import Data.Void data family Sing :: forall k. k -> Type data (~>) :: Type -> Type -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 newtype instance Sing (f :: k1 ~> k2) = SLambda { applySing :: forall t. Sing t -> Sing (Apply f t) } mkRefl :: n :~: j mkRefl = Refl right :: forall (r :: (x :~: y) ~> z). Sing r -> () right no = case mkRefl @x @y of Refl -> applySing no _ }}} {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180627 for x86_64-unknown-linux): tcTyVarDetails co_a1BG :: y_a1Bz[sk:1] ~# x_a1By[sk:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:497:22 in ghc:Var }}} On GHC 8.4, this simply errors: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:23:10: error: • Couldn't match type ‘n’ with ‘j’ ‘n’ is a rigid type variable bound by the type signature for: mkRefl :: forall k1 (n :: k1) (j :: k1). n :~: j at Bug.hs:22:1-17 ‘j’ is a rigid type variable bound by the type signature for: mkRefl :: forall k1 (n :: k1) (j :: k1). n :~: j at Bug.hs:22:1-17 Expected type: n :~: j Actual type: n :~: n • In the expression: Refl In an equation for ‘mkRefl’: mkRefl = Refl • Relevant bindings include mkRefl :: n :~: j (bound at Bug.hs:23:1) | 23 | mkRefl = Refl | ^^^^ Bug.hs:29:13: error: • Couldn't match type ‘Sing (Apply r t0)’ with ‘()’ Expected type: () Actual type: Sing (Apply r t0) • In the expression: applySing no _ In a case alternative: Refl -> applySing no _ In the expression: case mkRefl @x @y of { Refl -> applySing no _ } • Relevant bindings include no :: Sing r (bound at Bug.hs:27:7) right :: Sing r -> () (bound at Bug.hs:27:1) | 29 | Refl -> applySing no _ | ^^^^^^^^^^^^^^ Bug.hs:29:26: error: • Found hole: _ :: Sing t0 Where: ‘t0’ is an ambiguous type variable ‘y’, ‘x’, ‘k’ are rigid type variables bound by the type signature for: right :: forall k1 (x1 :: k1) (y1 :: k1) z (r :: (x1 :~: y1) ~> z). Sing r -> () at Bug.hs:(25,1)-(26,21) • In the second argument of ‘applySing’, namely ‘_’ In the expression: applySing no _ In a case alternative: Refl -> applySing no _ • Relevant bindings include no :: Sing r (bound at Bug.hs:27:7) right :: Sing r -> () (bound at Bug.hs:27:1) Valid substitutions include undefined :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => a (imported from ‘Prelude’ at Bug.hs:7:8-10 (and originally defined in ‘GHC.Err’)) | 29 | Refl -> applySing no _ | ^ }}} Note that this is distinct from #15142, as this is still reproducible on HEAD, even after commit 030211d21207dabb7a4bf21cc9af6fa5eb066db1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #15439: Refactor `printMinimalImports` into two functions and reexport them
by GHC 06 Aug '18

06 Aug '18

#15439: Refactor `printMinimalImports` into two functions and reexport them -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple imports,refactoring,source | plugins | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the `printMinimalImports` function finds set of minimal imports and prints them into file. * https://github.com/ghc/ghc/blob/0f5a63e3d763f18c683f076e0e96396166863f56/co… But it's more convenient to have function that returns set of minimal imports that can later be used by external tools like source plugins without need to parse content of `.import` file. And without need to copy- paste existing function. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15439> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5