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

Bug 353103

Summary: ConcurrentModificationException during resolver fragment processing
Product: [Eclipse Project] Equinox Reporter: Glyn Normington <glyn.normington>
Component: FrameworkAssignee: Thomas Watson <tjwatson>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: k2eric
Version: 3.7   
Target Milestone: 3.7.1   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on:    
Bug Blocks: 353054    
Attachments:
Description Flags
patch
none
fix + modified tests none

Description Glyn Normington CLA 2011-07-26 09:19:56 EDT 
A Virgo user reported the following stack trace when running the Virgo kernel. The kernel is using Equinox's State.resolve method to check for resolution errors. This appears to be an Equinox resolver bug.

java.util.ConcurrentModificationException: null
	at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
	at java.util.AbstractList$Itr.next(AbstractList.java:343)
	at org.eclipse.osgi.internal.module.ResolverBundle.detachFragment(ResolverBundle.java:488)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundle(ResolverImpl.java:1228)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveImport(ResolverImpl.java:1454)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundle(ResolverImpl.java:1221)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveImport(ResolverImpl.java:1454)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundle(ResolverImpl.java:1221)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveImport(ResolverImpl.java:1454)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundle(ResolverImpl.java:1221)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveImport(ResolverImpl.java:1454)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundle(ResolverImpl.java:1221)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveImport(ResolverImpl.java:1454)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundle(ResolverImpl.java:1221)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveImport(ResolverImpl.java:1454)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundle(ResolverImpl.java:1221)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles0(ResolverImpl.java:650)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolveBundles(ResolverImpl.java:547)
	at org.eclipse.osgi.internal.module.ResolverImpl.resolve(ResolverImpl.java:437)
	at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateImpl.java:481)
	at org.eclipse.osgi.internal.resolver.StateImpl.resolve(StateImpl.java:553)
	...

Steps to reproduce are in bug 353054, but are summarised here for simplicity:

1. Unzip fresh copy of Virgo Kernel 3.0.0.RC1 from:
http://www.eclipse.org/downloads/download.php?file=/virgo/milestone/VK/3.0.0.RC1/virgo-kernel-3.0.0.RC1.zip

2. Unzip the following into the kernel's repository/usr directory:
http://dl.dropbox.com/u/2487064/bug353054-repository-usr.zip

(I will delete this file when this bug is fixed)

3. Start the kernel by running bin/startup.sh. Observe stack trace and failure to start.

It seems that the cause may be in ResolverBundle where detachFragment makes a recursive call to itself (via hasUnresolvedConstraint) inside the for loop that gives the exception. The exception is due to the fact that an ArrayList<ResolverBundle> is used as the type for the 'fragments' instance field and ArrayList provides a "fail fast" iterator which throws ConcurrentModificationException if the underlying ArrayList is modified during an iteration (except via the iterator's own add or remove methods).
Comment 1 Thomas Watson CLA 2011-07-26 11:04:42 EDT 
Created attachment 200366 [details]
patch

This is a regression in 3.7.0.  The move to using a Java 5 style loop over the fragments collection introduced this.  In 3.6 the code used to make a copy of the array to iterate over each time to avoid the comodification error.
Comment 2 Thomas Watson CLA 2011-07-26 11:05:31 EDT 
Should fix this regression in 3.7.1.
Comment 3 BJ Hargrave CLA 2011-07-26 11:29:54 EDT 
You can still use a foreach loop over the array you create since you don't need "i" in the loop:

  for (ResolverBundle remainingFrag : remainingFrags) {
Comment 4 Thomas Watson CLA 2011-07-26 13:08:39 EDT 
Created attachment 200380 [details]
fix + modified tests

Thanks BJ, here is an updated patch + modified test to exercise this.

In testing I found an additional issue which was causing a potential for fragments to remain attached even if they should fail because of an unresolved constraint.  The issue was we were not correctly indicating the reason for detaching the fragment recursively which caused us to not consolidate common imports from other attached fragments.  So if more than one fragment had an import for a package that could not be resolved then we could end up with one or more of the fragments remaining attached.