Concurrent Modification
Concurrent modification exception while:
1. Performing analysis on a file
2. Updating editor runtimeBoth of these happen automatically at Eclipse startup, so they should be synchronized in some way.
Submitted by Nathan Bruning on 25 March 2010 at 13:38java.util.ConcurrentModificationException at java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:762) at java.util.WeakHashMap$KeyIterator.next(WeakHashMap.java:795) at org.strategoxt.imp.runtime.dynamicloading.Descriptor.reinitialize(Descriptor.java:103) at org.strategoxt.imp.runtime.Environment.registerUnmanagedParseTable(Environment.java:256) at org.strategoxt.imp.metatooling.loading.DynamicDescriptorLoader.updateResource(DynamicDescriptorLoader.java:185) at org.strategoxt.imp.metatooling.loading.DynamicDescriptorLoader.postResourceChanged(DynamicDescriptorLoader.java:144) at org.strategoxt.imp.metatooling.loading.DynamicDescriptorLoader.postResourceChanged(DynamicDescriptorLoader.java:148) at org.strategoxt.imp.metatooling.loading.DynamicDescriptorLoader.postResourceChanged(DynamicDescriptorLoader.java:148) at org.strategoxt.imp.metatooling.loading.DynamicDescriptorLoader.postResourceChanged(DynamicDescriptorLoader.java:148) at org.strategoxt.imp.metatooling.loading.DynamicDescriptorLoader.postResourceChanged(DynamicDescriptorLoader.java:148) at org.strategoxt.imp.metatooling.loading.DynamicDescriptorLoader$1.runInWorkspace(DynamicDescriptorLoader.java:127) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Issue Log
So what’s the resulting behavior? I’ve seen some ConcurrentModificationExceptions caused by IMP in the log sometimes, but they have no noticeable effect.
One of the two tasks will just fail.
Although it’s not a top-priority bug, Spoofax should synchronize it’s data accesses; this becomes more important when you’re using multiple Stratego-based plugin instances.
Looking at the stack trace again, I think I actually fixed this bug already for the upcoming version. It’s not actually concurrent modification (the table has proper synchronization), but reinitialize() loops over all elements of the table, calling some methods, and then one of those methods changes the table.
Log in to post comments