Skip to content

BlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible from another thread

GHC's runtime system throws a BlockedIndefinatelyOnMVar exception when the thread blocking an the MVar is the only one having a direct access to it. It assumes that there will be nothing written into the MVar in the future. This would be the correct behaviour if there were no weak references. The runtime system even throws the Exception when another thread still has a weak reference to the MVar. Consider the following example:

import Control.Concurrent
import System.Mem.Weak
import Data.Maybe
import Control.Monad

main = do
  m <- newEmptyMVar
  w <- mkWeakMVar m (return ())
  forkIO $ do
    threadDelay 1000000
    n <- deRefWeak w
    when (isJust n) $ putMVar (fromJust n) ()
  takeMVar m

At the time of takeMVar the forked thread has a weak reference to the MVar and it will put a value in it. However, the runtime system throws the Exception:

% ghc BlockingOnMVar.hs -threaded
Linking BlockingOnMVar ...
% ./BlockingOnMVar +RTS -N2      
BlockingOnMVar: thread blocked indefinitely in an MVar operation
Trac metadata
Trac field Value
Version 7.6.3
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Runtime System
Test case
Differential revisions
BlockedBy
Related
Blocking
CC simonmar
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information