Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,412
    • Issues 5,412
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 606
    • Merge requests 606
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #10793
Closed
Open
Issue created Aug 25, 2015 by Neil Mitchell@ndmitchellReporter

Incorrect blocked on MVar detection

Given the code:

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.

Trac metadata
Trac field Value
Version 7.10.1
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Runtime System
Test case
Differential revisions
BlockedBy
Related
Blocking
CC ndmitchell@gmail.com
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking