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,248
    • Issues 5,248
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 564
    • Merge requests 564
  • 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
  • #9295
Closed
Open
Issue created Jul 11, 2014 by edsko@edsko.net@trac-edsko

Deadlock in forkProcess

As part of forkProcess we discard all tasks except the one task that remains. As part of this we call freeTask, and freeTask in turn calls closeCondition and closeMutex, which are very thin wrappers around pthread_cond_destroy and phread_mutex_destroy. However, the behaviour of these functions is undefined when there are currently threads blocked on these condition variables/mutexes. In reality, this undefined behaviour often (though not always) results in a deadlock. Unfortunately, I don't have a minimal test case to demonstrate this, but in the large system on which I am testing this I am seeing these deadlocks rather frequently.

For the global mutex we don't attempt to call pthread_cond_destroy or pthread_mutex_destroy, but instead re-initialize them. The patch

https://phabricator.haskell.org/D59

does precisely that for the condition variables and mutexes associated with tasks. This is somewhat or a long way around, because we will then subsequently still call pthread_..._destroy, but it means that we don't have to mess with freeTask.

Trac metadata
Trac field Value
Version 7.8.2
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
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