August 2018 - ghc-tickets

[GHC] #13137: Dynamic linker not initialised.
by GHC 08 Aug '18

08 Aug '18

#13137: Dynamic linker not initialised. ----------------------------------------+--------------------------------- Reporter: djduke | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Attempting to build accelerate-llvm-1.0.0.0 cloned from the repo at https://github.com/AccelerateHS/accelerate-llvm, using: OSX 10.12.2 (Sierra) GHC 8.0.2 Command line tools for Xcode 8.2.1 [25 of 52] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o ) (GHC version 8.0.2 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [26 of 52] Compiling Data.Array.Accelerate.LLVM.Util ( Data/Array/Accelerate/LLVM/Util.hs, dist/build/Data/Array/Accelerate/LLVM/Util.o ) <no location info>: error: <command line>: can't load .so/.DLL for: /Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx-ghc-8.0.2 /libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib (dlopen(/Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx- ghc-8.0.2/libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib, 5): Symbol not found: __ZTIN4llvm11InstructionE Referenced from: /Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx-ghc-8.0.2 /libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib Expected in: flat namespace in /Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx- ghc-8.0.2/libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib) [27 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Ptr ( Data/Array/Accelerate/LLVM/CodeGen/Ptr.hs, dist/build/Data/Array/Accelerate/LLVM/CodeGen/Ptr.o ) <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ... so I have. I note previous tickets for "Dynamic linker not initialised", but not clear they are relevant due to different OS etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13137> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10355: Dynamic linker not initialised
by GHC 08 Aug '18

08 Aug '18

#10355: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: dpiponi | 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 | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I get this message: [ 3 of 24] Compiling Cable ( src/Cable.hs, dist/build/ui/ui- tmp/Cable.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug when building my code here: https://github.com/dpiponi/Moodler/tree/master/Moodler/src under Yosemite 10.10.2 So I'm reporting it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10355> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13607: Panic with profiled compiler: Dynamic linker not initialised
by GHC 08 Aug '18

08 Aug '18

#13607: Panic with profiled compiler: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are several Trac tickets floating around which mention this panic, including: * #9868 (ghc: panic! Dynamic linker not initialised) * #10355 (Dynamic linker not initialised) * #10919 (ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised) * #13137 (Dynamic linker not initialised.) * #13531 (GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file) However, none seem particularly simple to reproduce. I have a (marginally) easier way to trigger this panic. You'll need the following: * A copy of GHC HEAD built with the `prof` flavor. For reference, I am using GHC HEAD built against 1f4fd37efac4795493677d5df81c83d22eac5f74. * A single package built with `cabal-install`. For simplicity, I used `random`: {{{ $ cabal install random-1.1 -w ~/Software/ghc3/inplace/bin/ghc-stage2 }}} Once it's installed, you'll need to learn `random`'s package ID, which can be done with `ghc-pkg`. For instance: {{{ 3$ ~/Software/ghc3/inplace/bin/ghc-pkg describe random name: random version: 1.1 id: random-1.1-Gnn89iTXDuaz90MEyLmyr ... }}} * You'll need these three Haskell files: {{{#!hs -- Foo.hs {-# LANGUAGE TemplateHaskell #-} module Foo where import Language.Haskell.TH foo :: Bool foo = $(conE 'True) }}} {{{#!hs -- Foo2.hs {-# LANGUAGE TemplateHaskell #-} module Foo2 where import Language.Haskell.TH foo2 = $(conE 'False) }}} {{{#!hs -- Bar.hs module Bar where import Foo import Foo2 bar :: () bar = foo `seq` foo2 `seq` () }}} Once you have all of these, you can trigger the bug by invoking GHC like so: {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 -fforce-recomp Bar.hs -j2 -package-id random-1.1-Gnn89iTXDuaz90MEyLmyr [1 of 3] Compiling Foo ( Foo.hs, Foo.o ) <no location info>: error: <command line>: can't load .so/.DLL for: libHSrandom-1.1-Gnn89iTXDuaz90MEyLmyr.so (libHSrandom-1.1-Gnn89iTXDuaz90MEyLmyr.so: cannot open shared object file: No such file or directory) [2 of 3] Compiling Foo2 ( Foo2.hs, Foo2.o ) <no location info>: error: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170423 for x86_64-unknown-linux): Dynamic linker not initialised CallStack (from -prof): Linker.CAF (<entire-module>) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} In case it's important, this is using 64-bit Linux. cc'ing angerman, who requested an easier way to reproduce this panic in https://ghc.haskell.org/trac/ghc/ticket/13137#comment:6. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13607> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

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

08 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 07 Aug '18

07 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 07 Aug '18

07 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 07 Aug '18

07 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 07 Aug '18

07 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 07 Aug '18

07 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