forcedExports: StackOverFlow while exporting root and subpackage

[ruwen]

Hi!

I was able to produce a StackOverFlowError? using forcedExports.

Old forcedExports (taking from the plugins.xml)

org.eclipse.uml2.diagram.clazz.edit.helpers,
org.eclipse.uml2.diagram.clazz.edit.policies,
org.eclipse.uml2.diagram.clazz.links,
org.eclipse.uml2.diagram.clazz.parser,
org.eclipse.uml2.diagram.clazz.view.factories,
org.eclipse.uml2.diagram.clazz.expressions,
org.eclipse.uml2.diagram.clazz.preferences

Now we also wanted to export org.eclipse.uml2.diagram.clazz.parser.dependency (Notice: org.eclipse.uml2.diagram.clazz.parser is already exported!)

I added this to our grantedForcedExports.ini and our plugins.xml. Afterwards, I could not restart my eclipse. So I played around a little bit and came to the following conclusions:

1. If problem is the ini-file. If I remove org.eclipse.uml2.diagram.clazz.parser.dependency only from the file, I can start again.

2. I tested the whole thing again by adding org.eclipse.uml2.diagram.clazz.view. Some problem.

3. Originally somebody of my team (windows user) had this problem and ask me for help. So this problem is platform-independant.

I attached some files:

windows.txt: User did not restart his eclipse after modifying his ini-file, but he started a eclipse app using run. It gets started using -consoleLog. This is the console-output.

linux.txt: User did restart his eclipse: ./eclipse -debug -consoleLog

This bug can be reproduced:

- Check out version 225 (at the moment this is the current version) using  http://subversion.assembla.com/svn/n-ot-e of all the plugins in the UML2Tools_View directory and the de.nordakademie.uml2.diagram.clazz.custom plugin
- add the following line to your config.ini: otequinox.forced.exports.granted=@configuration/grantedForcedExports.ini
- copy the file grantedForcedExports.ini from the de.nordakademie.uml2.diagram.clazz.custom-plugin root to <your eclipse-root>/configuration/
- add the following line to the grantedForcedExports.ini: org.eclipse.uml2.diagram.clazz.parser.depency;x-friends:="de.nordakademie.uml2.diagram.clazz.custom", so it looks like this:

org.eclipse.uml2.diagram.clazz
[
	org.eclipse.uml2.diagram.clazz.parser.depency;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",
	org.eclipse.uml2.diagram.clazz.edit.helpers;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",
	org.eclipse.uml2.diagram.clazz.edit.policies;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",
	org.eclipse.uml2.diagram.clazz.links;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",
	org.eclipse.uml2.diagram.clazz.parser;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",
	org.eclipse.uml2.diagram.clazz.view.factories;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",
	org.eclipse.uml2.diagram.clazz.expressions;x-friends:="de.nordakademie.uml2.diagram.clazz.custom",
	org.eclipse.uml2.diagram.clazz.preferences;x-friends:="de.nordakademie.uml2.diagram.clazz.custom"
]

- save the file and start your eclipse

[ruwen]

Linuxstacktrace

[ruwen]

Windowstacktrace

[stephan]

Can reproduce on my machine.

Should be easy to analyze since there is only one location where we use a pattern matcher.

Unfortunately, using the exact same code in a little standalone app does not exhibit the error.

Need to dig in deeper.

[stephan]

BTW, depency doesn't seem to be the name of an existing package ;-)

[stephan]

workaround: pass the following arg to the vm when starting eclipse:

-Xss1m

Preferrably do this in eclipse.ini so that other vm args set in that file are not overridden by a command line arg -vmargs.

comment: the problem is actually not an infinite loop, as would have been my sure guess, but java.util.regex simply uses insanely much stack space, because matching is implemented using deep recursion. So any character added to you grantedForcedExports.ini may cause a StackOverflowError.

In my experiments setting stack size to 325k sufficed, so 1m should be safe for a while.

Still having to increase the stack size for this one parsing of forced exports is out of proportion, so we should not use java.util.regex for this purpose :(

[stephan]

Fixed in r19840.

With the next (unstable) release the workaround from comment:3 will no longer be needed.

Actually, handcoded scanning is even easier to maintain than the regular expressions we used until now.