Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » StackOverflowError when saving resource
StackOverflowError when saving resource [message #1736889] Mon, 04 July 2016 08:51 Go to next message
Vlad Acretoaie is currently offline Vlad AcretoaieFriend
Messages: 95
Registered: April 2014
Member
I am programmatically saving a resource using the save(Map options) method of the org.eclipse.emf.ecore.resource.Resource class. This particular method call has been in my code base for some time, and used to work.

However, after some recent changes to my Ecore models, the call throws a java.lang.StackOverflowError with the following trace:

java.lang.StackOverflowError
        at org.eclipse.emf.ecore.impl.EObjectImpl.eClass(EObjectImpl.java:263)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectImpl.java:1247)
	at com.myapp.MyClass.eIsSet(MyClass.java:218)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectImpl.java:1237)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectImpl.java:1252)
        at com.myapp.MyClass.eIsSet(MyClass.java:218)


The last four calls in the above trace are repeated in what appears to be an endless loop which causes the StackOverflowError.

I suspect that this is caused by one of the said Ecore changes, but it is difficult to pinpoint which one. I have of course regenerated my model code after the Ecore changes.

What would be a good way to approach solving this?

Cheers,
Vlad
Re: StackOverflowError when saving resource [message #1736919 is a reply to message #1736889] Mon, 04 July 2016 11:35 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Vlad,

What is at line com.myapp.MyClass.eIsSet(MyClass.java:218)? Which
feature is this? If it's a local feature of MyClass, I'd expect there
to be implementation code in MyClassImpl.eIsSet, not a call to super.
If there is a call to super, has the super class that is the direct
container of that feature been regenerated? I can only imagine this
happening if some base class has a new feature added, but hasn't been
regenerated. So best figure out which feature is involved, which class
is the direct container of that feature, and figure out where there is
no generated code for the eIsSet for that feature in the corresponding
Impl class.


On 04.07.2016 04:51, Vlad Acretoaie wrote:
> at org.eclipse.emf.ecore.impl.EObjectImpl.eClass(EObjectImpl.java:263)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectImpl.java:1247)
> at com.myapp.MyClass.eIsSet(MyClass.java:218)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectImpl.java:1237)
> at
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eIsSet(BasicEObjectImpl.java:1252)
> at com.myapp.MyClass.eIsSet(MyClass.java:218)


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: StackOverflowError when saving resource [message #1736952 is a reply to message #1736919] Mon, 04 July 2016 14:40 Go to previous messageGo to next message
Vlad Acretoaie is currently offline Vlad AcretoaieFriend
Messages: 95
Registered: April 2014
Member
Thank you for the very quick reply. After considering your suggestion and digging into the problem a bit deeper, I am now even more confused as to what is going on.

The MyClassImpl.eIsSet method does indeed contain implementation code. It looks like this:

  @Override
  public boolean eIsSet(int featureID) {
    switch (featureID) {
      case IMyPackage.A:
        return ....;
      case IMyPackage.B:
        return ...;
    }
    return super.eIsSet(featureID);
  }


Even though the classes in my code have been regenerated, featureID does not match any of the case branches in the above switch statement. The superclass whose eISet method is invoked is BasicEObjectImpl, a platform class.

Interestingly, I can check by looking at my Ecore model and at the generated code, including the generated instance of EPackageImpl, that all features declared in the Ecore model also appear in the generated code. I can also see when tracing that the feature identified by featureID exists in the generated code, but simply has a different ID than the one passed to the method above as featureID.

It appears as though the culprit is the saveFeatures method in the XMLSaveImpl class, which is responsible for generating the ID passed to the eIsSet method shown above. Somehow the generated ID does not correspond to the ID stored in the IMyPackage.A constant. One of the IDs is 10, and the other is 11.

I agree that this looks exactly as though the generated code is not up to date. However, I have re-generated it multiple times today.
Re: StackOverflowError when saving resource [message #1736959 is a reply to message #1736952] Mon, 04 July 2016 15:30 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Vlad,

Comments below.


On 04.07.2016 10:40, Vlad Acretoaie wrote:
> Thank you for the very quick reply. After considering your suggestion
> and digging into the problem a bit deeper, I am now even more confused
> as to what is going on.
>
> The MyClassImpl.eIsSet method does indeed contain implementation code.
> It looks like this:
>
>
> @Override
> public boolean eIsSet(int featureID) {
> switch (featureID) {
> case IMyPackage.A:
> return ....;
> case IMyPackage.B:
> return ...;
> }
> return super.eIsSet(featureID);
> }
>
>
> Even though the classes in my code have been regenerated, featureID
> does not match any of the case branches in the above switch statement.
> The superclass whose eISet method is invoked is BasicEObjectImpl, a
> platform class.
> Interestingly, I can check by looking at my Ecore model and at the
> generated code, including the generated instance of EPackageImpl, that
> all features declared in the Ecore model also appear in the generated
> code. I can also see when tracing that the feature identified by
> featureID exists in the generated code, but simply has a different ID
> than the one passed to the method above as featureID.
>
> It appears as though the culprit is the saveFeatures method in the
> XMLSaveImpl class, which is responsible for generating the ID passed
> to the eIsSet method shown above.
The ID of a feature is just its position in the list of
eAllStructuralFeatures, so not much room for this to go wrong.
> Somehow the generated ID does not correspond to the ID stored in the
> IMyPackage.A constant. One of the IDs is 10, and the other is 11.
Something has not been regenerated or not recompiled.
>
> I agree that this looks exactly as though the generated code is not up
> to date. However, I have re-generated it multiple times today.
Something didn't end up being @generated NOT or missing the @generated
such that it's not being regenerated? You mention IDs like 10 and 11,
but show code with only two features...

If this is a class with no base classes, which looks to be the case for
above, where the eIsSet of BasicEObjectImpl is being called. Look at how
many features are actually in the EClass at runtime. What are all their
names? Does the generated eIsSet for that class (and the base classes)
cover all those cases?


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: StackOverflowError when saving resource [message #1737048 is a reply to message #1736959] Tue, 05 July 2016 10:02 Go to previous messageGo to next message
Vlad Acretoaie is currently offline Vlad AcretoaieFriend
Messages: 95
Registered: April 2014
Member
Thank you once more for the suggestions. I finally solved the problem, and it was indeed related to code generation.

Namely, a generated package class (a class extending EPackage) was not being regenerated at all. Therefore, some of the feature IDs it declared were out of sync with the Ecore model. I solved the problem by deleting the class from the file system, thus "forcing" it to be re-generated from scratch. It appeared that anything else I did (I tried deleting some feature IDs from the class, for instance) would leave the generated class untouched, as if the generator did not attempt (or did not have permission) to modify it.

Do you have any thoughts as to what might be causing this? Could it be that under some circumstances (e.g. some property values set on the generator model) a generated class simply cannot be re-generated?
Re: StackOverflowError when saving resource [message #1737060 is a reply to message #1737048] Tue, 05 July 2016 12:16 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Vlad,

No, I've not seen ever that a class is not regenerated, except if the
existing target class has syntax errors or the newly generated class has
syntax errors. Typically such problems would be logged in the Error log...


On 05.07.2016 06:02, Vlad Acretoaie wrote:
> Thank you once more for the suggestions. I finally solved the problem,
> and it was indeed related to code generation.
>
> Namely, a generated package class (a class extending EPackage) was not
> being regenerated at all. Therefore, some of the feature IDs it
> declared were out of sync with the Ecore model. I solved the problem
> by deleting the class from the file system, thus "forcing" it to be
> re-generated from scratch. It appeared that anything else I did (I
> tried deleting some feature IDs from the class, for instance) would
> leave the generated class untouched, as if the generator did not
> attempt (or did not have permission) to modify it.
>
> Do you have any thoughts as to what might be causing this? Could it be
> that under some circumstances (e.g. some property values set on the
> generator model) a generated class simply cannot be re-generated?


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:for the PhD students among us: typesetting Emfatic in LaTeX
Next Topic:Illegal State Exception with EMF Transaction
Goto Forum:
  


Current Time: Thu Mar 28 14:05:21 GMT 2024

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

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

Back to the top