Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » StackOverflowError on EPackageRegistryImpl

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » StackOverflowError on EPackageRegistryImpl(Unable to launch product due to EMF initialization issue)

Show: Today's Messages :: Show Polls :: Message Navigator

StackOverflowError on EPackageRegistryImpl [message #1767424]

Wed, 05 July 2017 21:30

Babu M

Messages: 20
Registered: February 2012

Junior Member

By using neon, I am trying to setup a target and build a product out of this target.

A detailed log file is attached

When I try to launch product which is build from the targets.
I am experiencing a StackoverflowError. Any help is highly appreciated.

http://download.eclipse.org/technology/m2e/releases
http://download.eclipse.org/releases/neon/
http://download.eclipse.org/modeling/tmf/xtext/updates/composite/releases
http://repo1.maven.org/maven2/.m2e/connectors/m2eclipse-tycho/0.9.0/N/LATEST
http://download.eclipse.org/eclipse/updates/4.6
http://download.eclipse.org/technology/swtbot/releases/latest
http://download.eclipse.org/sphinx/previews
https://www.artop.org/containers/artop-sdk-update-site-4.6

The exception is as follows:

java.lang.StackOverflowError
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(Unknown Source)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:273)
	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:632)
	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:586)
	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:538)
	at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:525)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:325)
	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:345)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:423)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
	at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at autosar40.diagnosticextract.dcm.obdservice.mode_0x03_0x07_requestemissionrelateddtc.Mode_0x03_0x07_requestemissionrelateddtcFactory.<clinit>(Mode_0x03_0x07_requestemissionrelateddtcFactory.java:41)
	at autosar40.diagnosticextract.dcm.obdservice.mode_0x03_0x07_requestemissionrelateddtc.impl.Mode_0x03_0x07_requestemissionrelateddtcPackageImpl.<init>(Mode_0x03_0x07_requestemissionrelateddtcPackageImpl.java:1024)
	at autosar40.diagnosticextract.dcm.obdservice.mode_0x03_0x07_requestemissionrelateddtc.impl.Mode_0x03_0x07_requestemissionrelateddtcPackageImpl.init(Mode_0x03_0x07_requestemissionrelateddtcPackageImpl.java:1078)
	at autosar40.diagnosticextract.dcm.obdservice.mode_0x03_0x07_requestemissionrelateddtc.Mode_0x03_0x07_requestemissionrelateddtcPackage.<clinit>(Mode_0x03_0x07_requestemissionrelateddtcPackage.java:78)
	at sun.misc.Unsafe.ensureClassInitialized(Native Method)
	at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(Unknown Source)
	at sun.reflect.ReflectionFactory.newFieldAccessor(Unknown Source)
	at java.lang.reflect.Field.acquireFieldAccessor(Unknown Source)
	at java.lang.reflect.Field.getFieldAccessor(Unknown Source)
	at java.lang.reflect.Field.get(Unknown Source)
	at org.eclipse.emf.ecore.plugin.RegistryReader$EPackageDescriptor.getEPackage(RegistryReader.java:275)
	at org.eclipse.emf.ecore.impl.EPackageRegistryImpl.getEPackage(EPackageRegistryImpl.java:127)
	at

Attachment: .log
(Size: 300.32KB, Downloaded 33 times)

Report message to a moderator

Re: StackOverflowError on EPackageRegistryImpl [message #1767430 is a reply to message #1767424]

Thu, 06 July 2017 04:16

Ed Merks

Messages: 29327
Registered: July 2009

Senior Member

I see a bunch of warnings in the log that suggest you're likely to have problems looking up the correct implementation class from the package's nsURI:

!ENTRY org.eclipse.emf.ecore 2 0 2017-07-05 22:33:05.833
!MESSAGE Both 'org.artop.aal.autosar402' and 'org.artop.aal.autosar403' register a package for 'http://autosar.org/schema/r4.0/autosar40/er'

I'm not sure that would cause initialization problems though. In any case, looking at the stack overflow, I don't see duplicates so there isn't some circularity causing the problems; it's just a chain of 102 packages being initialized based on dependencies from one to the other. It looks like you need to increase the stack size: https://stackoverflow.com/questions/3700459/how-to-increase-the-java-stack-size
Note that if you don't want to increase the stack size for all threads, you might create a thread programmatically, with a large enough stack size to initialize the packages, and do the initialization on that thread.

Report message to a moderator

Re: StackOverflowError on EPackageRegistryImpl [message #1767448 is a reply to message #1767430]

Thu, 06 July 2017 08:19

Ed Willink

Messages: 5838
Registered: July 2009

Senior Member

Hi

Increasing the stack size may well make the problem go away. Not having both autosar402 and autosar403 installed may help. But fundamentally the very dubious practice of a huge number of nested installed packages appears to expose a weakness in the autogenerated Java EPackage initialization. It appears that many packages are ensuring that many other packages are initialized first in such a complex fashion that the stack trace duplicate entry detector fails to spot the duplicates. This appears to be poor AUTOSAR design in that everything depends on everything in a too cyclic graph rather than a directed tree. It is actually possible to get this problem with just EMF plus one other EPackage; it is solved by ensuring that EMF is explicitly initialized first.

Since you probably do not want to redesign AUTOSAR, I suggest that you write an AUTOSARResourcesUtil.init() that ensures that each AUTOSAR package is initialized in a disciplined order. Similar to UMLResourcesUtil.init() it can probably do quite a lot of other useful initialization jobs. Maybe it already exists and you neglected to call it.

Regards

Ed Willink

Report message to a moderator

Previous Topic:	[Edapt] DiagnosticException while migrating
Next Topic:	[EMF Forms] Table: Single column for different EStructuralFeatures

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 24 16:51:34 GMT 2018

.:: Contact :: Home ::.