Community
Participate
Working Groups
Build Identifier: 32 The following exception was seen (once) during product restart in from adopter product: java.lang.IndexOutOfBoundsException: index=7, size=6 at org.eclipse.emf.ecore.util.BasicFeatureMap.entryIndex(Unknown Source) at org.eclipse.emf.ecore.util.BasicFeatureMap.add(Unknown Source) at org.eclipse.emf.ecore.util.FeatureMapUtil$FeatureEList.add(Unknown Source) at org.eclipse.wst.common.internal.emf.utilities.ExtendedEcoreUtil.eSetOrAdd(Unknown Source) at org.eclipse.wst.common.internal.emf.resource.Translator.setMOFValue(Unknown Source) at org.eclipse.wst.common.internal.emf.resource.EMF2DOMAdapterImpl.primUpdateMOFMultiFeature(Unknown Source) at org.eclipse.wst.common.internal.emf.resource.EMF2DOMAdapterImpl.primUpdateMOFMultiFeature(Unknown Source) at org.eclipse.wst.common.internal.emf.resource.EMF2DOMAdapterImpl.updateMOFMultiFeature(Unknown Source) at org.eclipse.wst.common.internal.emf.resource.EMF2DOMAdapterImpl.updateMOFFeature(Unknown Source) at org.eclipse.wst.common.internal.emf.resource.EMF2DOMAdapterImpl.primUpdateMOF(Unknown Source) at org.eclipse.wst.common.internal.emf.resource.EMF2DOMAdapterImpl.updateMOF(Unknown Source) at org.eclipse.wst.common.internal.emf.resource.EMF2DOMAdapterImpl.primUpdateMOFMultiFeature(Unknown Source) Reproducible: Couldn't Reproduce Steps to Reproduce: This happened only once and is not reproducible. However, through this patch, I am proposing a defensive alternative to the existing code, so that we can avoid this issue in future.
Created attachment 168963 [details] patch This patch checks to see if the index is > the size of the array, and uses the index if its valid.
approve
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This exception, if it occurs, will cause the model to be in a bad state. * Is there a work-around? If so, why do you believe the work-around is insufficient? No known workarounds. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Tested this fix by running an end to end smoke test incuding rad restart. * Give a brief technical overview. Who has reviewed this fix? This fix has been reviewed by Chuck Bridgham. * What is the risk associated with this fix? No known risks.
I agree with defensive code and am approving, but do you have any idea how this could happen in the first place? Sounds like there is still an underlying problem lurking, and although this avoids the exception, do you know if this would be the correct behaviour if this happens again?
Committed to HEAD for WTP 3.2 RC 2
