Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 353103 - ConcurrentModificationException during resolver fragment processing
Summary: ConcurrentModificationException during resolver fragment processing
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Framework (show other bugs)
Version: 3.7   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.7.1   Edit
Assignee: Thomas Watson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 353054
  Show dependency tree
 
Reported: 2011-07-26 09:19 EDT by Glyn Normington CLA
Modified: 2011-07-26 14:20 EDT (History)
1 user (show)

See Also:

Attachments
patch (1.17 KB, patch)
2011-07-26 11:04 EDT, Thomas Watson CLA 		no flags Details | Diff
fix + modified tests (5.82 KB, patch)
2011-07-26 13:08 EDT, Thomas Watson CLA 		no flags Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.