change application can cause deadlock

[reprogrammer]

I've noticed several times that when users apply a change while Cascade's job are in progress, Eclipse freezes. This sounds like a deadlock.

[reprogrammer]

Change application should not conflict with tree computation. The tree computation should be performed on a copy of the original code and independent of changes to the original code.

[amchiclet]

The tree computation should not be touching the operation history.

java.lang.IllegalStateException: Cannot open an operation while one is already open
    at org.eclipse.core.commands.operations.DefaultOperationHistory.openOperation(DefaultOperationHistory.java:1324)
    at org.eclipse.ltk.internal.core.refactoring.UndoManager2.aboutToPerformChange(UndoManager2.java:139)
    at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:254)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2345)
    at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:306)
    at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:223)
    at checker.framework.quickfixes.FixerDescriptorApplier.performChangeOperation(FixerDescriptorApplier.java:78)
    at checker.framework.quickfixes.FixerDescriptorApplier.performChange(FixerDescriptorApplier.java:56)
    at checker.framework.quickfixes.FixerDescriptorApplier.apply(FixerDescriptorApplier.java:34)
    at checker.framework.change.propagator.ActionableMarkerResolution.apply(ActionableMarkerResolution.java:70)
    at checker.framework.errorcentric.view.views.ChangeComputationJob.run(ChangeComputationJob.java:48)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

[amchiclet]

When trying to set locks at the project level, the following exception is thrown.

    IProject project = resolution.getShadowProject().getProject().getProject();
    job.setRule(project);

java.lang.IllegalArgumentException: Attempted to beginRule: R/, does not match outer scope rule: P/ShadowOfShadowOfjolden-bh
    at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63)
    at org.eclipse.core.internal.jobs.ThreadJob.illegalPush(ThreadJob.java:134)
    at org.eclipse.core.internal.jobs.ThreadJob.push(ThreadJob.java:333)
    at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:85)
    at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:286)
    at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:118)
    at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:2283)
    at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2340)
    at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:306)
    at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:223)
    at checker.framework.quickfixes.FixerDescriptorApplier.performChangeOperation(FixerDescriptorApplier.java:76)
    at checker.framework.quickfixes.FixerDescriptorApplier.performChange(FixerDescriptorApplier.java:55)
    at checker.framework.quickfixes.FixerDescriptorApplier.apply(FixerDescriptorApplier.java:33)
    at checker.framework.change.propagator.ActionableMarkerResolution.apply(ActionableMarkerResolution.java:70)
    at checker.framework.errorcentric.view.views.ChangeComputationJob.run(ChangeComputationJob.java:48)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

[amchiclet]

It turns out that the call to

resolution.apply();

leads to the call to

ResourcesPlugin.getWorkspace().run(runnable, fSchedulingRule, IWorkspace.AVOID_UPDATE, pm);

which performs an atomic workspace operation.

[amchiclet]

Applying the change on the tree is waiting for the checker to complete running.

We tried removing calls to job.setUser(true) and that seemed to help a bit. However, we haven't completely been able to determine why applying a change has to wait.

[amchiclet]

The UndoableOperation seems to be trying to take a lock inside aboutToNotify() by calling

ResourcesPlugin.getWorkspace().checkpoint(false);

After we commented this line out, the changes were applied immediately.

[amchiclet]

We have validated that it is indeed the case that the background jobs are using a scheduling rule that conflicts with the undoable operation's scheduling rule. We tested this by synchronizing the Run() method in ChangeComputationJob, and the changes were able to be applied immediately.

The next step that might be good to try is to have our own scheduling rules, instead of using the project resource directly as the scheduling rule.

[amchiclet]

Another problem we found was that in order to compute the disabled nodes, we need to wait for the change computation jobs to finish because we are iterating on all the nodes.

See the method getChildren() in MarkerResolutionTreeNode.