Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » StackOverflowError on EPackageRegistryImpl(Unable to launch product due to EMF initialization issue)
StackOverflowError on EPackageRegistryImpl [message #1767424] Wed, 05 July 2017 21:30 Go to next message
Babu M is currently offline Babu MFriend
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 195 times)

Report message to a moderator

Re: StackOverflowError on EPackageRegistryImpl [message #1767430 is a reply to message #1767424] Thu, 06 July 2017 04:16 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33140
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.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: StackOverflowError on EPackageRegistryImpl [message #1767448 is a reply to message #1767430] Thu, 06 July 2017 08:19 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
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:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Wed Apr 24 19:53:47 GMT 2024

Powered by FUDForum. Page generated in 0.03658 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly