ArrayIndexOutOfBoundsException when calling BasicEList.toArray [message #1783498] |
Tue, 13 March 2018 16:32 |
|
Hello,
I noticed several bugs having this top-level stack:
java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at org.eclipse.emf.common.util.BasicEList.toArray(BasicEList.java:255)
see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=492508
https://bugs.eclipse.org/bugs/show_bug.cgi?id=494089
https://bugs.eclipse.org/bugs/show_bug.cgi?id=509806
https://issues.jboss.org/browse/FUSETOOLS-2833
I'm wondering what can cause this issue?
my initial thought was that 2 threads are accessing the same list but for instance in this case, a synchronized block has been used:
java.lang.ArrayIndexOutOfBoundsException
at org.eclipse.emf.common.util.BasicEList.toArray(BasicEList.java:255)
at java.util.ArrayList.<init>(ArrayList.java:178)
at org.eclipse.wst.common.internal.emf.utilities.ResourceIsLoadingAdapter.findAdapter(ResourceIsLoadingAdapter.java:47)
at org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.waitForResourceToLoadIfNecessary(CompatibilityXMIResourceImpl.java:381)
at org.eclipse.wst.common.internal.emf.resource.CompatibilityXMIResourceImpl.isLoaded(CompatibilityXMIResourceImpl.java:373)
at org.eclipse.wst.common.componentcore.internal.ModuleStructuralModel.getAndLoadLocalResource(ModuleStructuralModel.java:375)
at org.eclipse.wst.common.internal.emfworkbench.integration.EditModel.getResource(EditModel.java:683)
at org.eclipse.wst.common.componentcore.internal.ModuleStructuralModel.getPrimaryResource(ModuleStructuralModel.java:332)
at org.eclipse.wst.common.componentcore.internal.ModuleStructuralModel.prepareProjectModulesIfNecessary(ModuleStructuralModel.java:240)
at org.eclipse.wst.common.componentcore.internal.ModuleStructuralModel.getPrimaryRootObject(ModuleStructuralModel.java:119)
at org.eclipse.wst.common.componentcore.internal.StructureEdit.getComponentModelRoot(StructureEdit.java:471)
at org.eclipse.wst.common.componentcore.internal.StructureEdit.getWorkbenchModules(StructureEdit.java:506)
at org.eclipse.wst.common.componentcore.internal.StructureEdit.getComponent(StructureEdit.java:949)
at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathUpdater$FindNodeJob.findNode(J2EEComponentClasspathUpdater.java:234)
at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathUpdater$FindNodeJob.findNode(J2EEComponentClasspathUpdater.java:240)
at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathUpdater$FindNodeJob.findNode(J2EEComponentClasspathUpdater.java:240)
at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathUpdater$FindNodeJob.access$0(J2EEComponentClasspathUpdater.java:226)
at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathUpdater$FindNodeJob$1.run(J2EEComponentClasspathUpdater.java:265)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathUpdater$FindNodeJob.run(J2EEComponentClasspathUpdater.java:258)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
see http://git.eclipse.org/c/webtools-common/webtools.common.git/tree/plugins/org.eclipse.wst.common.emf/wtpemf/org/eclipse/wst/common/internal/emf/utilities/ResourceIsLoadingAdapter.java?id=50c592cce40e2a2465ea3594a48bbca088ff10c6#n46
[code]
EList<Adapter> resourceAdapters = aResource.eAdapters();
synchronized(resourceAdapters) {
ArrayList<Adapter> resourceAdaptersCopy = new ArrayList<Adapter>(resourceAdapters);
adapter = (ResourceIsLoadingAdapter) getAdapter(resourceAdaptersCopy, ResourceIsLoadingAdapter.class);
}
[code]
So what are the possibilities that can cause this error? How to investigate?/fix it? Any ideas?
Regards,
Aurélien Pupier - Red Hat
Senior Software Engineer in Fuse Tooling team
|
|
|
Re: ArrayIndexOutOfBoundsException when calling BasicEList.toArray [message #1783550 is a reply to message #1783498] |
Wed, 14 March 2018 05:58 |
Ed Merks Messages: 33142 Registered: July 2009 |
Senior Member |
|
|
It must be a threading issue or it would be easy to reproduce everywhere, all the time. Sure you can have a synchronization guard, but unless all threads have such a guard, the guard won't do much good. So if, for example, you have a background thread that does the above, but you're using item providers in the display thread to display the model, the display thread will also attach adapters and it will do so without a guard. Note also that org.eclipse.emf.ecore.impl.MinimalEObjectImpl.eAdapters() creates a new list on each call so the same pattern as above would be useless because each caller sees a different list instance. One brute force fix would be to syncExec to the display thread but that might lead to deadlock.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03083 seconds