#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): Thanks for all the awesome debugging work here, I think we finally have all the pieces! @rwbarton's analysis seems plausible to me too. A single-entry thunk can still be entered multiple times in a parallel setting, and if eager blackholing is on then it is possible that a thread can get blocked indefinitely. Threads blocked indefinitely are detected by the GC as deadlocked, and receive an exception, which results in the `<loop>` message. The fix should be simple: just don't do eager blackholing for single-entry thunks. Regarding this comment: {{{ // NB. Blackholing is *compulsory*, we must either do lazy // blackholing, or eager blackholing consistently. See Note // [upd-black-hole] in sm/Scav.c. }}} It means every update frame must refer to a black hole by the time the GC runs, it's an invariant the GC relies on. It shouldn't be a problem here because it only applies to update frames. I can reword the comment so it's clearer. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10414#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler