[GHC] #10414: Buggy behavior with threaded runtime (-N1 working, -N2 getting into <<loop>>)

GHC ghc-devs at haskell.org
Fri Jul 3 15:03:13 UTC 2015


#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


More information about the ghc-tickets mailing list