Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 340985 - Applying a SemanticModification throws StackOverflowError
Summary: Applying a SemanticModification throws StackOverflowError
Status: CLOSED FIXED
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.0.0   Edit
Hardware: All All
: P3 critical (vote)
Target Milestone: M7   Edit
Assignee: Jan Koehnlein CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-25 12:59 EDT by Bernd Kolb CLA
Modified: 2017-09-19 18:00 EDT (History)
3 users (show)

See Also:
sven.efftinge: indigo+


Attachments
Errorlog (609.53 KB, text/plain)
2011-03-25 13:00 EDT, Bernd Kolb CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Kolb CLA 2011-03-25 12:59:51 EDT
Build Identifier: 2.0.0.v201103151224 - the one used at Eclipsecon

Applying a SemanticModification (Uncapitalize name) in the Domainmodel example throws StackOverflowError. This seems however to be not specific to that very example but a general problem.

Reproducible: Always

Steps to Reproduce:
1. Use the Domainmodel example as provided by Xtext
2. create a new File with the following content
entity Person {
	age : int
	op PrintAge() : String { 
		"This person is of age " + age
	}
	
	op print() : String {
		PrintAge
	}

}

entity Car {
	
	owner: Person
	
	op printAgeOfOwner() : String { 
		owner.PrintAge()
	}
	
}

3. try to fix the waring using the quickfix
--> Eclipse throws StackOverflowError
Comment 1 Bernd Kolb CLA 2011-03-25 13:00:51 EDT
Created attachment 191924 [details]
Errorlog
Comment 2 Jan Koehnlein CLA 2011-04-11 08:34:11 EDT
The error occurs when unloading the inferred model before linking: Using a tree iterator, we set the EObject URI and remove all adapters and on all children first and eventually on the root element. When removing the root element's DefaultTextEditComposer - a *content* adapter - we go into a nice cycle, as it tries to resolve the children which in turn try to resolve the parent.

Another issue appears with Ecore: EPackages sets the ePackage on their children to null when being proxified, thus resolving them. So we cannot proxify ecore models starting with the children. 

I fixed the GenericUploader and added a test.
Comment 3 Karsten Thoms CLA 2017-09-19 17:49:21 EDT
Closing all bugs that were set to RESOLVED before Neon.0
Comment 4 Karsten Thoms CLA 2017-09-19 18:00:19 EDT
Closing all bugs that were set to RESOLVED before Neon.0