[GHC] #10793: Incorrect blocked on MVar detection

[GHC]

#10793: Incorrect blocked on MVar detection
-------------------------------------+-------------------------------------
              Reporter:              |             Owner:  simonmar
  NeilMitchell                       |
                  Type:  bug         |            Status:  new
              Priority:  normal      |         Milestone:
             Component:  Runtime     |           Version:  7.10.1
  System                             |
              Keywords:              |  Operating System:  Windows
          Architecture:              |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
             Test Case:              |        Blocked By:
              Blocking:              |   Related Tickets:
Differential Revisions:              |
-------------------------------------+-------------------------------------
 Given the code:

 {{{#!hs
 import Control.Concurrent

 main = do
     v <- newEmptyMVar
     forkFinally (putStrLn $ let x = x in x) (putMVar v)
     print =<< takeMVar v
 }}}

 The spawned thread should raise a {{{NonTermination}}} exception (assuming
 idle GC), then put it in the MVar {{{v}}}, which should cause the main
 thread to abort printing {{{Left <<loop>>}}}.

 However, in reality, the main thread aborts with {{{Exception: thread
 blocked indefinitely in an MVar operation}}}.

 My debugging shows that the spawned thread raises {{{NonTermination}}} and
 at the same time the main thread raises {{{BlockedIndefinitelyOnMVar}}}.
 Of course, the main thread is not really blocked on the exception, and
 after the finally bit runs, the MVar is filled. Adding tracing shows that
 the {{{putMVar}}} is called.

 Hypothesis is that the GC notices it can raise the non-termination
 exception, and then opportunistically excludes that thread from further GC
 scanning, and detects the MVar is unreferenced, raising the subsequent
 exception. Of course, given you can catch the exception, that isn't safe.
 Roman Leshchinskiy worries that in the wrong circumstances the MVar might
 really be being GC'd and thus could corrupt memory. This issue was
 detected while debugging an error in the Shake build system for GHC
 itself.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10793>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler