Community
Participate
Working Groups
Build Identifier: 3.6 NotificationManager tries to lock the workspace regardless of whether it is already locked. The implementation of Workspace#setTreeLocked(boolean) disallows this and exceptions are logged: org.eclipse.core.runtime.AssertionFailedException: assertion failed: The workspace tree is already locked at org.eclipse.core.runtime.Assert.isTrue(Assert.java:111) at org.eclipse.core.internal.resources.Workspace.setTreeLocked(Workspace.java:1868) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:274) at org.eclipse.core.internal.events.NotificationManager.handleEvent(NotificationManager.java:266) at org.eclipse.core.internal.resources.Workspace.broadcastEvent(Workspace.java:307) at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1483) ... org.eclipse.core.runtime.AssertionFailedException: assertion failed: The workspace tree is already locked at org.eclipse.core.runtime.Assert.isTrue(Assert.java:111) at org.eclipse.core.internal.resources.Workspace.setTreeLocked(Workspace.java:1868) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:274) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:148) at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:313) at org.eclipse.core.internal.resources.Workspace.aboutToBuild(Workspace.java:244) at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:513) at org.eclipse.core.internal.resources.Project.build(Project.java:94) at org.eclipse.ui.actions.BuildAction.invokeOperation(BuildAction.java:221) at org.eclipse.ui.actions.WorkspaceAction.execute(WorkspaceAction.java:162) at org.eclipse.ui.actions.WorkspaceAction$2.runInWorkspace(WorkspaceAction.java:483) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Reproducible: Sometimes
Created attachment 179785 [details] proposed patch
How have you managed to achieve this? Do you have a test? AFAICS it should not be possible to trip this assertion. The post change notification should only be fired while the workspace lock is held, and this variable is to prevent a notification listener from changing resources in-line with the notification. It would be interesting to know how you're managing to trip this exception. Is it possible for you to attach a full thread dump when the assertion happens?
Created attachment 199768 [details] Logs I had never seen that "Workspace already locked" in the past, but since I upgraded to Indigo, I saw it twice - this time on Linux RHEL 5.6. Find attached ZIP with several logs from my system (the Workspace .log as well as full configuration etc). This is Eclipse 3.7 SDK plus lots of proprietary plugins. I think what I did was initiate a build, then create a new Debug Configuration for launching an Eclipse App as Debuggee (maybe while Eclipse was still building). My launch config is in the ZIP ("wrwb.launch").
If you can reproduce this, it would be useful to get a full threadump when the issue occurs. Perhaps in a runtime eclipse, set a breakpoint which suspends all threads when the assertion fails.
Hm, reproducing might be hard. But for sure I can put a "stop the world" breakpoint on the assertion for whenever I run a debuggee (I think so far I only saw it in my host eclipse). Do you know whether the code itself, in addition to throwing the assertion, could log a Thread Dump?
(In reply to comment #5) Sorry I should have actually taken a look at your logfile... This assertion trips because two threads are attempting to perform WS notification simultaneously => WS is broken as both acquire the WS lock. This is the fault of the ClearCase native plugins you've got installed: !ENTRY org.eclipse.core.jobs 4 2 2011-07-15 18:36:20.875 !MESSAGE Deadlock detected. All locks owned by thread Worker-18 will be suspended. !STACK 0 java.lang.IllegalStateException at org.eclipse.core.internal.jobs.DeadlockDetector.reportDeadlock(DeadlockDetector.java:599) ... at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:286) at org.eclipse.team.core.RepositoryProvider.map(RepositoryProvider.java:94) at com.rational.clearcase.RSCMService.providerCheck(RSCMService.java:5843) at com.rational.clearcase.RSCMService.connectProject(RSCMService.java:364) at com.rational.clearcase.RSCMService.visit(RSCMService.java:5570) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:69) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:80) at org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:49) at com.rational.clearcase.RSCMService.resourceChanged(RSCMService.java:4204) The result is the WS lock is released in CC's thread, leading to the refresh job running and tripping the assertion. In this case I think life is hard for the ClearCase plugin as it's _always_ unsafe to acquire a lock in resource change thread, see bug 249951. The fix I see is to relax the constraint that the WS is locked during res delta notification making the API more asynchronous. This may affect consumers: bug 249951 comment 28 onwards, but I think it would be better than what we have now.
Saw this at least twice after upgrading to 2018-12. It seems like Buildship 3.0 is locking the workspace in a way that severely breaks other features related to workspace locking, like the process to update the SVN Cache performed by Subclipse. Fixed in Buildship 3.0.1 (see https://discuss.gradle.org/t/buildship-3-0-1-is-now-available/29890). In any case, the assertion failure described in this bug does occur, but unfortunately due to the many trials I did I lost the stack trace.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
