Skip to content

Conversation

copybara-service[bot]
Copy link

Prevent endless loop in lock cycle detection. The following scenario would previously fail:

  • T1: Enter lockOrDetectPotentialLocksCycle:
    • Lock CAF.class, add itself to lockThreadIsWaitingOn, unlock CAF.class
    • Lock the cycle detecting lock (CDL)
    • Lock CAF.class, mark itself as lockOwnerThread, remove itself from lockThreadIsWaitingOn
    • Exit lockOrDetectPotentialLocksCycle
  • T1: Re-enter lockOrDetectPotentialLocksCycle:
    • Lock CAF.class, add itself to lockThreadIsWaitingOn, unlock CAF.class
      T2: Enter lockOrDetectPotentialLocksCycle
    • Lock CAF.class, invoke detectPotentialLocksCycle.

At this point, detectPotentialLocksCycle will now loop forever, because the lockOwnerThread is also in lockThreadIsWaitingOn. During the course of looping forever, it will OOM, because it's building up an in-memory structure of what it thinks are cycles.

The solution is to avoid the re-entrant T1 from adding itself to lockThreadIsWaitingOn if it's already the lockOwnerThread. It's guaranteed that it won't relinquish the lock concurrently, because it's the exact same thread that owns it.

Fixes #1635 and Fixes #1510

@copybara-service copybara-service bot closed this Apr 18, 2023
@copybara-service copybara-service bot deleted the test_524376697 branch April 18, 2023 17:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cycle detection in a multi-thread environment leads to OutOfMemoryError
0 participants