Community
Participate
Working Groups
Created attachment 175804 [details] thread dump I've just had a backtrace in which seems to suggest that the workspace OrderedLock is lost. User was using Eclipse 3.6.0 (org.eclipse.core.jobs_3.5.0.v20100515.jar) Back trace attached. I took a heap dump, the deadlock table looks like: 0 0 1 0 0 0 0 Folder 0 0 1 0 0 -1 -1 Workspace Root 0 -1 1 0 0 0 0 Project 0 0 1 0 0 0 0 Multi Rule {Project} 2 0 -1 -1 -1 0 0 OrderedLock lockThreads main Worker-336 Worker-338 Worker-312 Worker-333 Worker-324 ModalContext The workspace lock currentOperationThread is main at depth 2, but AFAICS that isn't possible from the thread dump. Just found the user's .log file, having restarted there are a number of weird LocakManager exceptions: !ENTRY org.eclipse.core.resources 2 10035 2010-08-03 21:42:06.886 !MESSAGE The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes. !ENTRY org.eclipse.core.jobs 4 2 2010-08-03 21:42:37.594 !MESSAGE LockManager.handleException !STACK 0 java.lang.IllegalArgumentException: A thread with no real locks was chosen to resolve deadlock. at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63) at org.eclipse.core.internal.jobs.DeadlockDetector.realLocksForThread(DeadlockDetector.java:495) at org.eclipse.core.internal.jobs.DeadlockDetector.lockWaitStart(DeadlockDetector.java:400) at org.eclipse.core.internal.jobs.LockManager.addLockWaitThread(LockManager.java:158) at org.eclipse.core.internal.jobs.OrderedLock.doAcquire(OrderedLock.java:174) at org.eclipse.core.internal.jobs.OrderedLock.acquire(OrderedLock.java:110) at org.eclipse.core.internal.jobs.OrderedLock.acquire(OrderedLock.java:84) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:118) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1914) at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1655) at org.eclipse.cdt.internal.core.pdom.PDOMManager$3.syncronizeProjectSettings(PDOMManager.java:740) at org.eclipse.cdt.internal.core.pdom.PDOMManager$3.run(PDOMManager.java:724) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) !ENTRY org.eclipse.core.jobs 4 2 2010-08-03 21:42:37.623 !MESSAGE LockManager.handleException !STACK 0 java.lang.Exception: :: F/algo_.../.../.launches, F/algo_.../.launches, F/algo_.../.settings, F/algo_.../src, F/algo_.../streams, F/algo_.../.launches, F/algo_.../.settings, F/algo_.../src, MultiRule[P/algo_...,org.eclipse.cdt.internal.core.pdom.PDOMManager$PerInstanceSchedulingRule@45ad71f0], OrderedLock (0), main : -1, -1, -1, -1, -1, -1, -1, 1, 0, -1, Worker-10 : 0, 1, 1, 1, 1, 0, 0, 0, 1, -1, ------- at org.eclipse.core.internal.jobs.LockManager.handleInternalError(LockManager.java:204) at org.eclipse.core.internal.jobs.LockManager.addLockWaitThread(LockManager.java:176) at org.eclipse.core.internal.jobs.OrderedLock.doAcquire(OrderedLock.java:174) at org.eclipse.core.internal.jobs.OrderedLock.acquire(OrderedLock.java:110) at org.eclipse.core.internal.jobs.OrderedLock.acquire(OrderedLock.java:84) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:118) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1914) at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1655) at org.eclipse.cdt.internal.core.pdom.PDOMManager$3.syncronizeProjectSettings(PDOMManager.java:740) at org.eclipse.cdt.internal.core.pdom.PDOMManager$3.run(PDOMManager.java:724) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Unfortunately the log is silent for the period just before the deadlock. (The previous exception occured in a notification in an AutoBuild thread -- which indicates the Workspace lock wasn't held by main then.
The only way I can see this happening would be due to bug 262032. It's possible for the deadlock detector to suspend locks held by the UI thread while the UI thread is running code within those locks. This occurs because {a}syncExecs are processed while waiting for scheduling rules (in ThreadJob#joinRun). The scheduling rule blocked on isn't removed from the deadlock graph while the asyncExecs are run, leading to false positive deadlock detected and potential suspension of the UI's locks while the UI thread is running. When the other thread finishes, the UI's locks are restored - potentially after the code holding the lock has finished running.
*** Bug 321696 has been marked as a duplicate of this bug. ***
I've managed to reproduce this relatively reliably. I think this may be caused by Bug 262032.
Not seen since Bug 262032 fixed.
