Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,324
    • Issues 4,324
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 388
    • Merge Requests 388
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #9401

Closed
Open
Opened Aug 03, 2014 by Michael Snoyman@snoyberg

MVar deadlock exceptions cause exceptions in later MVar ops

Take the following code:

import Control.Concurrent
import Control.Concurrent.MVar
import Control.Exception

main :: IO ()
main = do
    var <- newEmptyMVar
    _ <- forkIO $ do
        res <- try $ newEmptyMVar >>= takeMVar
        putMVar var res
        putStrLn "Successfully filled var"

    res <- readMVar var `onException` do
        putStrLn "Received exception, delaying..."
        threadDelay 1000000
        res <- readMVar var
        putStrLn $ "After delay, res is: " ++ show res

    print (res :: Either SomeException Int)
    putStrLn "Exiting..."

On line 9, an MVar deadlock exception is thrown, which is caught by try. That result is then put into the var MVar. On line 13, I readMVar to get this value. I would expect it to return the exception previously thrown, as a Left value. Instead, a new exception is thrown. I say new, because if I switch over to using STM instead of an MVar, I get a different exception (STM transaction instead of MVar deadlock).

With the program as above, my output is:

Successfully filled var
Received exception, delaying...
After delay, res is: Left thread blocked indefinitely in an MVar operation
async14.hs: thread blocked indefinitely in an MVar operation

I originally filed this as an issue against the async package: https://github.com/simonmar/async/issues/14

Trac metadata
Trac field Value
Version 7.8.2
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Runtime System
Test case
Differential revisions
BlockedBy
Related
Blocking
CC simonmar
Operating system
Architecture
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#9401