This change prevents an endless loop in: ReentrantCycleDetectingLock.…

…detectPotentialLocksCycle()

Due to how code in ReentrantCycleDetectingLock.lockOrDetectPotentialLocksCycle() is synchronized,
its possible for a thread to both own/hold a lock (according to ReentrantCycleDetectingLock.lockOwnerThread)
and wait on the same lock (according to CycleDetectingLock.lockThreadIsWaitingOn).
In this state, if another thread tries to hold the same lock an endless loop will occur when calling detectPotentialLocksCycle().

The change adds a workaround, forcing the cycle detection to exit if the above condition is met.

Workaround for: google#1510

core/src/com/google/inject/internal/CycleDetectingLock.java

@@ -249,6 +249,9 @@ private ListMultimap<Thread, ID> detectPotentialLocksCycle() {
  MultimapBuilder.linkedHashKeys().arrayListValues().build();
  // lock that is a part of a potential locks cycle, starts with current lock
  ReentrantCycleDetectingLock<?> lockOwnerWaitingOn = this;
+ // Its possible the lock owner thread has not removed itself yet from the waiting-on-lock list.
+ // So we remove it here, to prevent an endless loop. See #1510.
+ lockThreadIsWaitingOn.remove(lockOwnerWaitingOn.lockOwnerThread);
  // try to find a dependency path between lock's owner thread and a current thread
  while (lockOwnerWaitingOn != null && lockOwnerWaitingOn.lockOwnerThread != null) {
  Thread threadOwnerThreadWaits = lockOwnerWaitingOn.lockOwnerThread;