Hi all,

I have run into a StackOverflowError problem when attaching
EContentAdapters to deep EMF models (more than 1000 levels deeps). You
can see the recursion in this stack trace:

at
org.eclipse.emf.ecore.impl.MinimalEObjectImpl$1ArrayDelegatingAdapterList.didAdd(MinimalEObjectImpl.java:489)
at
org.eclipse.emf.ecore.impl.MinimalEObjectImpl$1ArrayDelegatingAdapterList.didAdd(MinimalEObjectImpl.java:1)
at
org.eclipse.emf.common.util.ArrayDelegatingEList.addUnique(ArrayDelegatingEList.java:389)
at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:301)
at
org.eclipse.emf.ecore.util.EContentAdapter.addAdapter(EContentAdapter.java:349)
at
org.eclipse.emf.ecore.util.EContentAdapter.setTarget(EContentAdapter.java:219)
at
org.eclipse.emf.ecore.util.EContentAdapter.setTarget(EContentAdapter.java:182)
at
org.eclipse.emf.ecore.impl.MinimalEObjectImpl$1ArrayDelegatingAdapterList.didAdd(MinimalEObjectImpl.java:489)
at
org.eclipse.emf.ecore.impl.MinimalEObjectImpl$1ArrayDelegatingAdapterList.didAdd(MinimalEObjectImpl.java:1)
at
org.eclipse.emf.common.util.ArrayDelegatingEList.addUnique(ArrayDelegatingEList.java:389)
at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:301)
at
org.eclipse.emf.ecore.util.EContentAdapter.addAdapter(EContentAdapter.java:349)
at
org.eclipse.emf.ecore.util.EContentAdapter.setTarget(EContentAdapter.java:219)
at
org.eclipse.emf.ecore.util.EContentAdapter.setTarget(EContentAdapter.java:182)

I have tried to increase the stack size using -Xss and that does help,
but I have to increase it quite a bit (multiple MiB, depending on model
depth) to handle deep models and with Eclipse having quite a few threads
running, that would end up using a lot of memory.

I was a bit surprised to see that I could execute the same piece of code
multiple times and that it would sometimes throw a StackOverflowError
and sometimes not. It could for instance happen that it works fine the
first time, fails the second time, and works fine again the third time.
But after running the same code multiple times (e.g. 10) it would either
consistently fail or consistently succeed. I suspect that the JIT (and
HotSpot) code is using the same stack and that this explains why it
seems to be unpredictable.

While I don't see anything EMF could do differently here, I was
wondering if other people have run into the same problem and how they
dealt with it.

I am currently considering running some code during startup of the tool
which would trigger the JIT for the involved code and would then make
StackOverflowErrors less probable to occur.

Here is a simple JUnit test I have been using to do my testing:

public class StackOverflowTest {

@Test
public void testStackOverflow() {
test(20000, 1); // OK
// test(1315, 0); // NOK
// test(1315, 1); // OK
}

private void test(final int depth, final int warmupReps) {
for (int i = 0; i < warmupReps; i++) {
try {
deepModel(depth);
} catch (StackOverflowError e) {}
}
deepModel(depth);
}

private Resource deepModel(final int depth) {
Resource r = new
ResourceFactoryImpl().createResource(URI.createURI("foo:/bar"));
EPackage pkg = EcoreFactory.eINSTANCE.createEPackage();
r.getContents().add(pkg);
for (int i = 0; i < depth; i++) {
EPackage nested = EcoreFactory.eINSTANCE.createEPackage();
pkg.getESubpackages().add(nested);
pkg = nested;
}
new EContentAdapter().setTarget(r);
return r;
}

}

Regards,

--knut

Hi Erdal,

That is a good question. You may find it hard to believe, but one model
I have to deal with has a depth of over 3000 elements! And what may even
sound stranger this is a model produced by an Xtext parser when loading
a particular hand-written source file. The source file conforms to the
grammar of some GPL and contains an expression using almost 3000 string
concatenation operators like this:

"a " + var1 + " b " + var2 + ...

Of course it would be possible to break this expression up into multiple
separate expressions. But the problem I have is that I run into the
StackOverflowError when loading this particular source file in the Xtext
editor...

If the StackOverflowError can't be avoided in some elegant and
transparent way, I will have to find a way to detect this problem and
report it to the user, while still allowing him to edit the source file
in the editor. This may prove a bit tricky.

Regards,

--knut

>