Skip to content
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

Closed
reprogrammer opened this issue May 7, 2014 · 8 comments
Closed

change application can cause deadlock #66

reprogrammer opened this issue May 7, 2014 · 8 comments
Labels
Milestone

Comments

@reprogrammer
Copy link
Owner

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 reprogrammer added this to the Next milestone May 7, 2014
@reprogrammer
Copy link
Owner Author

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 pushed a commit that referenced this issue Jul 21, 2014
@amchiclet
Copy link
Collaborator

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 pushed a commit that referenced this issue Jul 21, 2014
@amchiclet
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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.

amchiclet pushed a commit that referenced this issue Aug 7, 2014
computing disabled nodes need not wait for the computation job to finish. (#66)
amchiclet pushed a commit that referenced this issue Aug 7, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants