Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 320878

Summary:	[refactoring] DynamicValidationStateChange throws away valid changes after 30 minutes
Product:	[Eclipse Project] JDT	Reporter:	Markus Keller <markus.kell.r>
Component:	UI	Assignee:	Markus Keller <markus.kell.r>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	daniel_megert, jtk499, markus.kell.r, michael.mess
Version:	3.7
Target Milestone:	4.3 M1
Hardware:	All
OS:	All
Whiteboard:

Description Markus Keller

2010-07-26 05:50:13 EDT

I20100720-0800, has been like this forever

I ran the Infer Generic Type Arguments refactoring and left the preview open for > 30 minutes. When I tried to continue and apply the changes, I got the ConcurrentModificationException below.

Initial changes should not be DynamicValidationStateChanges that throw away their children. Only undo changes should clean up after a while.

Fix idea: Add a new constructor to DynamicValidationStateChange that prevents cleanup for that change (but implements it for Undo/Redo changes).


java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.remove(AbstractList.java:357)
at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:297)
at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.access$0(DynamicValidationStateChange.java:1)
at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange$1.run(DynamicValidationStateChange.java:98)
at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:4777)
at org.eclipse.jdt.internal.corext.refactoring.changes.DynamicValidationStateChange.perform(DynamicValidationStateChange.java:101)
at org.eclipse.ltk.core.refactoring.CompositeChange.perform(CompositeChange.java:278)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation$1.run(PerformChangeOperation.java:258)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation.executeChange(PerformChangeOperation.java:306)
at org.eclipse.ltk.internal.ui.refactoring.UIPerformChangeOperation.executeChange(UIPerformChangeOperation.java:92)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:223)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975)
at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)

Comment 1 Markus Keller

2010-09-09 05:33:35 EDT

Rajesh, can you please have a look?

We need to keep the clearing of children in the Undo case, since refactoring changes can be big, and they would otherwise be around for too long.

To avoid having to change all clients, please change the default behavior such that children are not cleared, and add a new (private) constructor that is only used from createUndoChange(..).

Comment 2 Markus Keller

2012-06-12 09:03:48 EDT

I couldn't reproduce the original problem any more.

I reduced DynamicValidationStateChange#LIFE_TIME and tried to provoke resource changes (e.g. by enabling auto-refresh and changing a file in an external editor), but never got the ConcurrentModificationException.

Closing for now (without taking any action).

Comment 3 Markus Keller

2012-06-22 07:54:48 EDT

*** Bug 383080 has been marked as a duplicate of this bug. ***

Comment 4 Markus Keller

2012-06-22 07:57:00 EDT

Michael, do you remember anything unusual about the execution of the refactoring? Did you click the Preview button and then leave the computer unattended for > 30 minutes? Or did a build take place in the background?

Comment 5 Michael Meß

2012-06-25 02:44:35 EDT

The refactoring didn't use more than 5 minutes, until it failed.
I am not sure that I didn't leave a preview open for more than 30 minutes on that day, but I don't think so.

Maybe it could be because I was moving packages to a subpackage.

My Idea behind this is that: (Of course this is not eclipse)
When I do something like this at the bash shell, I get this:
 $ mkdir subdir
 $ mv * subdir/
mv: cannot move `subdir' to a subdirectory of itself, `subdir/subdir'

Maybe subdir was selected unintentionally (maybe even internally in eclipse?) when moving to it?
Or maybe eclipse depends on something in the directory to stay constant while doing the move, maybe this won't happen when moving to another package which is not a subpackage of the current location.
Maybe eclipse will move something to the subdirectory while it is contained in a list which is currently iterated.

About building: I have "Build automatically" activated, but I don't think (but don't know sure) that eclipse was building in that time.

Comment 6 Markus Keller

2012-07-05 12:53:52 EDT

I still can't explain why a workspace change notification can occur while a refactoring dialog is open. The workspace should be locked at that time.

Anyway, it's not too hard to avoid premature deletions of changes, so I just implemented that. Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=8e2605d3dff4c11b7a58ad084d4d7aa400f2c023

Comment 7 Jörg Thönnes

2012-07-06 05:26:50 EDT

Hmmm, it seems that the above link does not work: Cannot connect to git.eclipse.org

Comment 8 Markus Keller

2012-07-09 09:07:46 EDT

> Cannot connect to git.eclipse.org

Yeah, I heard the eclipse.org webserver had intermittent connection problems over the weekend. Should be back to normal now.