#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by rwbarton: Old description:

Compiling the test case with:

ghc -O2 -threaded -eventlog -rtsopts ghc-bug.hs

Now, trying with some inputs and -N2 $ ./ghc-bug 7 +RTS -N2 => ghc-bug: <<loop>> $ ./ghc-bug 6 +RTS -N2 => ghc-bug: <<loop>> $ ./ghc-bug 5 +RTS -N2 => 3125 $ ./ghc-bug 5 +RTS -N2 ghc-bug: <<loop>>

Reducing the number of capabilities to 1, it works for those inputs $ ./ghc-bug 7 +RTS -N1

As a side-note, the problem only happens randomly with small inputs (on my hardware), and it seems to go away with bigger inputs (the [http://lpaste.net/132564/ original testcase] felt a bit more deterministic, but I think the testcase in the ticket is good enough)

I only tested this with GHC 7.8.4 (on Debian), but people on IRC reported the same behavior with GHC 7.10.1 on OS X and Debian

Similar bug: [10218] (-fno-cse and -flate-dmd-anal didn't help with this)

{{{#!hs import Control.Applicative import Control.Monad

import Control.Parallel.Strategies

import System.Environment

newtype ParList a = ParList { unParList :: [a] }

nil :: ParList a nil = ParList [] cons :: a -> ParList a -> ParList a cons x (ParList xs) = ParList (x:xs)

instance Functor ParList where fmap = liftM

instance Applicative ParList where pure = return (<*>) = ap

instance Monad ParList where return = ParList . return {- v code that doesn't work -} (ParList xs) >>= f = ParList (withStrategy (parListChunk 8 rseq) (xs

...

...

= unParList . f)) --(ParList xs) >>= f = ParList (concat (parMap rseq (unParList . f) xs)) {- ^ code that works -}

type Pair = (Int, [Int])

loop' :: Pair -> ParList Pair loop' (size,qns) = go 1 where go n | n > size = nil | otherwise = cons (size, n:qns) (go (n+1))

worker :: Int -> Pair -> [Pair] worker n = unParList . go n where go 1 = loop' go n = loop' >=> go (n-1)

main :: IO () main = do [n] <- (read <$>) <$> getArgs print $ length (worker n (n,[]))

}}}

New description: Compiling the test case with: ghc -O2 -threaded -eventlog -rtsopts ghc-bug.hs Now, trying with some inputs and -N2 $ ./ghc-bug 7 +RTS -N2 => ghc-bug: <<loop>> $ ./ghc-bug 6 +RTS -N2 => ghc-bug: <<loop>> $ ./ghc-bug 5 +RTS -N2 => 3125 $ ./ghc-bug 5 +RTS -N2 ghc-bug: <<loop>> Reducing the number of capabilities to 1, it works for those inputs $ ./ghc-bug 7 +RTS -N1 As a side-note, the problem only happens randomly with small inputs (on my hardware), and it seems to go away with bigger inputs (the [http://lpaste.net/132564/ original testcase] felt a bit more deterministic, but I think the testcase in the ticket is good enough) I only tested this with GHC 7.8.4 (on Debian), but people on IRC reported the same behavior with GHC 7.10.1 on OS X and Debian Similar bug: #10218 (-fno-cse and -flate-dmd-anal didn't help with this) {{{#!hs import Control.Applicative import Control.Monad import Control.Parallel.Strategies import System.Environment newtype ParList a = ParList { unParList :: [a] } nil :: ParList a nil = ParList [] cons :: a -> ParList a -> ParList a cons x (ParList xs) = ParList (x:xs) instance Functor ParList where fmap = liftM instance Applicative ParList where pure = return (<*>) = ap instance Monad ParList where return = ParList . return {- v code that doesn't work -} (ParList xs) >>= f = ParList (withStrategy (parListChunk 8 rseq) (xs

...

= unParList . f)) --(ParList xs) >>= f = ParList (concat (parMap rseq (unParList . f) xs)) {- ^ code that works -}

type Pair = (Int, [Int]) loop' :: Pair -> ParList Pair loop' (size,qns) = go 1 where go n | n > size = nil | otherwise = cons (size, n:qns) (go (n+1)) worker :: Int -> Pair -> [Pair] worker n = unParList . go n where go 1 = loop' go n = loop' >=> go (n-1) main :: IO () main = do [n] <- (read <$>) <$> getArgs print $ length (worker n (n,[])) }}} -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by AlexET): Compiling with `-debug` I sometimes get {{{ BrokenCode: internal error: ASSERTION FAILED: file rts/Schedule.c, line 570 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by michaelt): This came into my head again, and can be simplified, and I think clarified, like so: {{{#!hs import Control.Parallel.Strategies import System.Environment parConcatMapN :: Int -> Int -> (a -> [a]) -> a -> [a] parConcatMapN chunksize depth step = go depth where go 0 = (:[]) go n = withStrategy (parListChunk chunksize rseq) . concatMap (go (n-1)) . step main :: IO () main = do depth:_ <- fmap (map read) getArgs print $ length (test depth) test depth = parConcatMapN 3 depth show 'x' -- i.e. iterate (concatMap show) 'x' !! depth }}} We keep re-chunking, but do not respect the chunking we already did, in the would-be progress through {{{ 'x' '\'''x''\'' '\'''\\''\'''\'''\'''x''\'''\'''\\''\'''\'' ... }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'd love it to be fixed in 7.10.2, but first someone needs to volunteer to look into what is wrong, and hopefully find out how to fix it. Is it a bug in a library? In the RTS? In the compiler? Help needed! Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): That's extremely helpful, thank you Reid. I'm guessing that the culprit, somehow, is this code in `CoreToStg`: {{{ upd_flag | isSingleUsed (idDemandInfo bndr) = SingleEntry | otherwise = Updatable }}} This arranges not to black-hole a thunk that is used at most once. Can you try with `-fkill-one-shot`? That switches off this optimisation, and I bet it'll make the program work. Assuming that does fix it, the next question is: is it just the `CoreToStg` `upd_flag`? (`-fkill-one-shot` affects more things than just that one spot.) The next thing I'd do would be just to comment out the `SingleEntry` case above, rebuild the compiler, and check that the bug is gone. I'm 95% sure that it'll will, but worth checking. Next. If some thunk is being marked `SingleEntry`, and that that is causing the bug: * Which thunk is it? * Is it really single-entry? (I.e. is the analysis right or not) If you `-ddump-stg` and look for thunks marked `\s`, those are the single- entry ones. There probably aren't very many. If it's very few, we could look at the "is the analysis right?" question. If it's many, we'll need to find a way to narrow it down somehow. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): Lazy blackholing will still take place for thunks that are not blackholed by eager blackholing, because we have no way to distinguish between an eager-blackholed and a lazy-blackholed thunk in the runtime. We had bugs in this area in the past, see #5226. I'm not sure this helps, but it's possible that the cardinality analysis is correct and this is a runtime bug. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by michaelt): I reduced this a little further so that it just uses the Monad instance and the two basic combinators: {{{#!hs rparWith s a = Eval $ \s0 -> spark# r s0 where r = case s a of Eval f -> case f realWorld# of (# _, a' #) -> a' runEval :: Eval a -> a runEval (Eval x) = case x realWorld# of (# _, a #) -> a }}} and a non-recursive but monotonously layered concrete function. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by michaelt): And a bit more compressed, for what it may be worth: {{{#!hs {-# LANGUAGE MagicHash, UnboxedTuples #-} import GHC.Exts newtype Eval a = Eval {runEval :: State# RealWorld -> (# State# RealWorld, a #)} -- inline sequence :: [Eval a] -> Eval [a] well_sequenced :: [Eval a] -> Eval [a] well_sequenced = foldr op (Eval $ \s -> (# s, [] #)) where op e es = Eval $ \s -> case runEval e s of (# s', a #) -> case runEval es s' of (# s'', as #) -> (# s'', a : as #) -- seemingly demonic use of spark# ill_sequenced :: [Eval a] -> Eval [a] ill_sequenced as = Eval $ spark# (case well_sequenced as of Eval f -> case f realWorld# of (# _, a' #) -> a') main :: IO () main = print ((layer . layer . layer . layer . layer) show 'y') where layer :: (Char -> String) -> (Char -> String) layer f = (\(Eval x) -> case x realWorld# of (# _, as #) -> concat as) . well_sequenced . map ill_sequenced . map (map (\x -> Eval $ \s -> (# s, x #))) . chunk' . concatMap f . show }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I took a look at the generated STG for par2.hs before and after the cardinality analysis commit. Before, there are no `\s` thunks at all. After, there are two. One is in {{{ Main.main_go [Occ=LoopBreaker] :: [[GHC.Types.Char]] -> [GHC.Types.Char] [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType , Unf=OtherCon []] = \r srt:SRT:[] [ds_s1nu] case ds_s1nu of _ { [] -> [] []; : y_s1ny [Occ=Once] ys_s1nz [Occ=Once] -> let { sat_s1pj [Occ=Once, Dmd=] :: [GHC.Types.Char] [LclId, Str=DmdType] = \s srt:SRT:[] [] Main.main_go ys_s1nz; } in GHC.Base.++ y_s1ny sat_s1pj; }; }}} This comes from the Core {{{ Main.main_go [Occ=LoopBreaker] :: [[GHC.Types.Char]] -> [GHC.Types.Char] [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType ] Main.main_go = \ (ds_XrA :: [[GHC.Types.Char]]) -> case ds_XrA of _ { [] -> GHC.Types.[] @ GHC.Types.Char; : y_arg ys_arh -> GHC.Base.++ @ GHC.Types.Char y_arg (Main.main_go ys_arh) } }}} which presumably comes from the use of `concat` in `layer`. This happens even when I build the program with `-fkill-absence -fkill-one-shot`. Could that be because base was built with cardinality analysis enabled? I don't entirely see how, but I can try rebuilding the libraries with `-fkill- absence -fkill-one-shot`. Anyways I guess the main question, which I'm not sure how to answer, is whether the fact that this thunk is marked as single-entry is correct. The other single-entry thunk is, I think, very similar and arises from `concatMap`: {{{ {- note $wlayer_r1m6 :: (GHC.Types.Char -> GHC.Base.String) -> GHC.Prim.Char# -> GHC.Base.String [GblId, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []] w3_r1ma :: GHC.Types.Char -> GHC.Base.String [GblId, Arity=1, Str=DmdType, Unf=OtherCon []] -} Main.main_go2 [Occ=LoopBreaker] :: [GHC.Types.Char] -> [GHC.Types.Char] [GblId, Arity=1, Str=DmdType , Unf=OtherCon []] = \r srt:SRT:[(r8, Main.main_go2), (r1m6, $wlayer_r1m6), (r1ma, w3_r1ma)] [ds_s1oh] case ds_s1oh of _ { [] -> [] []; : y_s1ol [Occ=Once!] ys_s1oq [Occ=Once] -> case y_s1ol of _ { GHC.Types.C# ww1_s1oo [Occ=Once] -> let { sat_s1pv [Occ=Once, Dmd=] :: [GHC.Types.Char] [LclId, Str=DmdType] = \s srt:SRT:[(r8, Main.main_go2)] [] Main.main_go2 ys_s1oq; } in case $wlayer_r1m6 w3_r1ma ww1_s1oo of sat_s1pu { __DEFAULT -> GHC.Base.++ sat_s1pu sat_s1pv; }; }; }; }}} I'm going to see what happens when I inline the definitions of `concat` and `concatMap` into this module. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Michael, Reid, that is super-helpful. The cardinality analysis is plain wrong, so now we know just what is happening. I'm working on a fix. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I think I've finally come up with at least part of a plausible explanation. Tell me if this seems right... Suppose I have a heap object whose initial value is {{{ x = \u [] concat [[1],[]] -- using "\u []" as syntax for "updatable thunk", -- otherwise normal Core syntax (not STG) }}} and suppose first some thread evaluates `x` to WHNF. Using the definition of `concat` as `main_go` from above, this will allocate a single-entry thunk `y = \s [] concat []`, and then calling `(++)` will lead to {{{ x = 1 : z y = \s [] concat [] z = \u [] (++) [] y }}} At this point the heap has the following property (*) The heap contains a single-entry thunk (`y`) and a regular thunk (`z`) such that entering the regular thunk will cause the single-entry thunk to be entered as well. (The key point is that the single-entry thunk has already been allocated on the heap, in contrast to a situation in which entering a regular thunk would cause a ''new'' single-entry thunk to be allocated, possibly entered, and then become garbage, all before evaluation of that regular thunk is complete.) Now, consider the following execution path of two threads A and B. * Both threads enter `z` simultaneously (before either manages to overwrite it with a black hole, if eager blackholing was enabled when we compiled `(++)`; otherwise before either manages to update it to an indirection). * Thread A does the case analysis inside `(++)` and enters `y`, and overwrites it with a black hole before thread B does anything else. * Now thread B does the case analysis inside `(++)` and enters `y`, but `y` has been overwritten with a black hole so thread B blocks. But `y` is never going to be updated, so thread B will block forever. This is bad! * Finally thread A finishes evaluating `y` (to `[]`) and then updates `z` accordingly. But thread B is still blocking on the black hole and even if it could get unblocked by some mechanism (say in the GC) there's no longer enough information on the heap to recover the correct value of `y` and allow thread B to continue. This doesn't exactly explain why the programs in this ticket <<loop>>, but a thread becoming permanently blocked is equally bad behavior I think. Some extra evidence that something like this is going on is that if I inline the definition of `(++)` into par2.hs as well, so that it is compiled with eager blackholing enabled, the program <<loop>>s much less frequently, just a few percent of the time as opposed to over half the time. That would match up with a smaller window of simultaneity in the first step of the execution trace above. If this analysis is correct, then assuming we want to continue to allow threads to enter thunks in an unsynchronized way (to avoid prohibitive locking costs), it seems we have to ensure that the condition (*) never holds, at least when eager blackholing is enabled. Generating single-entry thunks is still okay as long as they never survive as live heap objects after the thunk that allocated them has been reduced to WHNF. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): We need Simon Marlow's advice here. What you say does seem plausible: * With lazy blackholing, a single-entry thunk will never be black-holed. Lazy black-holing only black-holes thunks with an update frame on the stack, and single-entry thunks do not push an update frame. So that could explain why `-feager-blackholing` is required. * Rather to my surprise, a single-entry thunk is black-holed. I can't see any good reason why this happens. Look at `StgCmmClosure.blackHoleOnEntry`. * Re comment:22 we need Simon to say. It would be pretty bad if every module had to be compiled consistently. However I note that the comment in `Scav.c` is in code that messes with update frames, and so single-entry thunks probably don't matter. Even if all this is right, we still don't know why we get `<<loop>>`. I'm assuming that this means we have entered a black hole, ''that is under evaluation by this thread''; but suddenly I'm not sure. (For a black hole being evaluated by another thread, we'd block.) I suggest you try making `blackHoleOnEntry` return False for single-entry thunks. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): The actual cause of the <<loop>> here seems to be that two threads are each blocking on a black hole that is being evaluated, or more likely has been evaluated but not updated, by the other thread. I attached a complete `-Ds` log above, but the relevant lines are {{{ ... 0.011574 7ff6be7fc700: cap 1: thread 6 stopped (blocked on black hole owned by thread 5) ... 0.011808 7ff6c6700740: cap 0: thread 5 stopped (blocked on black hole owned by thread 6) ... }}} I didn't work out exactly how this can arise, but it probably involves two single-entry thunks and two ordinary thunks whose evaluations force both of the single-entry thunks, but in different orders. Changing `blackHoleOnEntry` for single-entry thunks as suggested did fix `par2.hs`. I'm going to test the other examples in this ticket now. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | Phab:D10414 -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => patch * differential: => Phab:D10414 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:27 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1040 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"aaa0cd20fdaf8e923e3a083befc2612154cba629/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="aaa0cd20fdaf8e923e3a083befc2612154cba629" Don't eagerly blackhole single-entry thunks (#10414) In a parallel program they can actually be entered more than once, leading to deadlock. Reviewers: austin, simonmar Subscribers: michaelt, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1040 GHC Trac Issues: #10414 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>) -------------------------------------+------------------------------------- Reporter: exio4 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1040 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler