-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
change application can cause deadlock #66
Comments
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. |
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) |
…undos in the tree computation. (#66)
When trying to set locks at the project level, the following exception is thrown.
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) |
It turns out that the call to
leads to the call to
which performs an atomic workspace operation. |
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. |
The UndoableOperation seems to be trying to take a lock inside aboutToNotify() by calling
After we commented this line out, the changes were applied immediately. |
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. |
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. |
computing disabled nodes need not wait for the computation job to finish. (#66)
…to be disabled once they are available. (#66)
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.
The text was updated successfully, but these errors were encountered: