Bug 430704

Comment 1 Scott Lewis 2014-03-19 11:04:31 EDT

Does this occur repeatably?   If so, please describe the steps to reproduce.

Comment 2 Stephan Wahlbrink 2014-03-19 11:15:32 EDT

(In reply to Scott Lewis from comment #1)
> Does this occur repeatably?

No, as usual for such concurrency bugs.

It is allowed to call cancel from any thread? So the bug is obviously - also an iterator of a synchronized map/set can throw a ConcurrentModificationException

Comment 3 Scott Lewis 2014-03-19 12:30:42 EDT

(In reply to Stephan Wahlbrink from comment #2)
> (In reply to Scott Lewis from comment #1)
> > Does this occur repeatably?
> 
> No, as usual for such concurrency bugs.
> 
> It is allowed to call cancel from any thread? So the bug is obviously - also
> an iterator of a synchronized map/set can throw a
> ConcurrentModificationException

Yes, I got that...thanks.   

I still would ask that you describe the sequence of user actions (p2/Eclipse update I assume) that led to this CME...even if you can't reproduce.  The reason is that I would like to understand better when it's likely to occur...in Eclipse in particular...but in other situations as well.  

Also...what version of Eclipse was used?

Thanks.

Comment 4 Stephan Wahlbrink 2014-03-19 13:09:41 EDT

Hi Scott,

it was a new Eclipse Classic IDE installation, first plug-in installation. I finished the install wizard (agreed licenses) and when the download progress was shown, the Eclipse error window popped up.

The complete log entry:

eclipse.buildId=4.4.0.I20140318-0830
java.version=1.7.0_51
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE
Framework arguments:  -showlocation
Command-line arguments:  -os win32 -ws win32 -arch x86_64 -data ... -showlocation

Created Time: 2014-03-19 15:05:54.553

org.eclipse.core.jobs
Error
Wed Mar 19 15:22:08 CET 2014
An internal error occurred during: "File Transport Cancel Handler".

java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926)
	at java.util.HashMap$KeyIterator.next(HashMap.java:960)
	at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1067)
	at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.cancel(HttpClientRetrieveFileTransfer.java:251)
	at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer$3.cancel(HttpClientRetrieveFileTransfer.java:1016)
	at org.eclipse.equinox.internal.p2.transport.ecf.FileReader$CancelHandler.run(FileReader.java:152)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

Comment 5 Scott Lewis 2014-03-19 15:08:46 EDT

Fix (for both httpclient4 and httpclient3 providers) pushed to master:

httpclient4 provider
http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/commit/?id=57b2df2315db1b837e9bca428debab3af900813c

httpclient3 provider
http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/commit/?id=fccff721935973648b96bd2af6f4d0a2d9b56bae

Unfortunately I wasn't able to reproduce the original CME either before or after these changes, but my belief is that this change will prevent the CME under all conditiions.

ECF's builder will be rebuilding and running our automated tests for the next few hours, and after that's complete I will resolve this bug and open a new bug for p2/Eclipse to consume the new version of ECF filetransfer prior to M7.

Thanks for the report.

Comment 6 Scott Lewis 2014-03-19 15:52:24 EDT

Fix has passed the ECF automated tests, and so I'm going to resolve this bug as fixed.   If you are able to reproduce with any subsequent versions of ECF filetransfer (httpclient4 or httpclient), please reopen with comment on what version of ECF filetransfer is being used.

The incorporation of this fix into p2/Eclipse will be either occur via bug 429930 or a new bug (David William's decision as stated on https://bugs.eclipse.org/bugs/show_bug.cgi?id=429930#c2