Bug 451053 - Frequent internal error "Loading models"
Summary: Frequent internal error "Loading models"
Status: RESOLVED FIXED
Alias: None
Product: Ecoretools
Classification: Modeling
Component: General (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 7
: P3 major
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: needinfo
Depends on: 430086 477205
Blocks:
  Show dependency tree
 
Reported: 2014-11-11 16:50 EST by Johan Van Noten CLA
Modified: 2016-05-17 13:58 EDT (History)
1 user (show)

See Also:


Attachments
Log containing explained messages + exceptions. (971.66 KB, text/plain)
2014-11-11 16:50 EST, Johan Van Noten CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Johan Van Noten CLA 2014-11-11 16:50:50 EST
Created attachment 248587 [details]
Log containing explained messages + exceptions.

Environment:
* Luna SR1
* EcoreTools 2.x nightly, based on Sirius 2.x nightly (both updated today)

Scenario:
* "Normal" editing on an ecore model. About 20 classes, quite some relations, quite some documentation.
* Documentation layer active
* Quite frequent documentation editing.
* Quite frequent restructuring: (re)moving relationships, classes etc.

Problem:
* During editing, frequently (several times an hour) a popup appears with "NullPointerException". Eclipse can still properly be closed.
* After restart of Eclipse and opening the affected project a message shows:
  An internal error occurred during: "Loading models".
* When invoking a repair:
  Repair error. Reason: Could not run repair process.
  (Eclipse log with exceptions in attachment)

Additional info:
* Same problem existed on Sirius 1. After upgrade, problems did not really diminish (rather increase), but the 2.x repair seemingly works better. Reported issues are for the currently in use 2.x versions.
* My experiments led me to conclude that I can obtain a successful repair of my aird file when I first open the genmodel, perform a reload and only then start a repair.

Next actions:
I have no direct way to reproduce this, so I don't know how to be of best assistance to you in solving this annoying behaviour. 
Since the issue is frequent, it should be possible for me to send you a "problematic" ecore/genmodel/aird combination. 
If useful, let me know.
Comment 1 Cedric Brun CLA 2014-11-12 04:13:45 EST
Hi, and thanks for your detailled report.

A project enabling the reproduction of the issue with a list of step to follow to get to it would indeed be very helpfull.

It looks like the NPE during "repair" comes from GenModel elements which have been "detached" from their corresponding element.
(java.lang.NullPointerException
	at org.eclipse.emf.codegen.ecore.genmodel.impl.GenTypedElementImpl.isListType(GenTypedElementImpl.java:334)
	at org.eclipse.emf.codegen.ecore.genmodel.impl.GenClassImpl$12.accept(GenClassImpl.java:2175)
	at org.eclipse.emf.codegen.ecore.genmodel.impl.GenBaseImpl.collectGenFeatures(GenBaseImpl.java:1582)
	at org.eclipse.emf.codegen.ecore.genmodel.impl.GenClassImpl.getLabelFeatureCandidates(GenClassImpl.java:2168)
	at org.eclipse.emf.codegen.ecore.genmodel.impl.GenClassImpl.getLabelFeature(GenClassImpl.java:2531)
	at org.eclipse.emf.codegen.ecore.genmodel.impl.GenClassImpl.eGet(GenClassImpl.java:2660)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1011)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1003)
	at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:998)
	at org.eclipse.sirius.ecore.extender.tool.internal.ReferencesResolver.resolveCrossReferences(ReferencesResolver.java:100)
	at org.eclipse.sirius.ecore.extender.tool.internal.ReferencesResolver.doResolveAll(ReferencesResolver.java:93)
	at org.eclipse.sirius.ecore.extender.tool.internal.ReferencesResolver.resolve(ReferencesResolver.java:74)
	at org.eclipse.sirius.ecore.extender.tool.api.ModelUtils.resolveAll(ModelUtils.java:418)
	
)

Is that the same NPE you got while you were using the tool ? Before restarting ?
EcoreTools installs a listener which triggers the GenModel.reload() when it detects one of the changes made in the Ecore model has enough impact to invalidate the genmodel, it might be a case where this detection fails and the reload does not get launched.

Once the genmodel gets in a "broken" state the "repair" process chokes on the same issues as no "reload" is automatically launched if there is no change made in the editor. 

I can also see some CCE in your log file which are related to Bug 430086 but it doesn't look like it is directly related to the issue with the genmodel.
Comment 2 Cedric Brun CLA 2014-11-19 05:03:09 EST
I could not reproduce it and am needing slightly more details to go forward.

What do you mean by "Normal editing", are you only editing the ecore through the graphical modeler ? Are you using the Ecore reflective editor at the same time ?
You mention "refactoring," again, are you doing all of these operations in the context of the graphical editor or are some of them done using another editor ?
Comment 3 Johan Van Noten CLA 2014-11-20 09:41:06 EST
Cédric, I understand your difficulty and need for more info.
I had to work on something else for the time being, so my additional experience with this issue is limited. Here some answers to your questions:

Q: Are you only editing the ecore through the graphical modeler? 
A: Yep, exclusively through the graphical modeler.

Q: Are you using the Ecore reflective editor at the same time ?
A: No

Q: You mention "refactoring," again, are you doing all of these operations in the context of the graphical editor or are some of them done using another editor ?
A: Exclusively the graphical modeler


Some potentially relevant info on my behaviour:
* When I experience the issue, it seems that the NullPointerException window contains severel NPEs. I do not always notice this window, so I still briefly continue working with the NPEs already on my other screen.
* When I have the NPEs on the screen, I still save the latest state. Does that corrupt anything?
* After a repair, it are usually the documentation boxes on the diagram that seem to have shifted their place (back to auto-layout). For me, the "documentation" layer is active all the time, while a "normal user" maybe uses it less.

What I could propose is that I make:
* A snapshot of my model
* A screencast of an editing session till failure
* A snapshot of the model at the moment of the failure
* Send you this
Would that help?
Comment 4 Cedric Brun CLA 2016-05-17 09:51:59 EDT
I realize it's been a long time and I dropped the ball on this one. Sorry about that.

Is that an environment you are still using ? did you upgrade to more recent versions ?
Comment 5 Johan Van Noten CLA 2016-05-17 13:23:20 EDT
Cédric, we've upgraded using both Mars.2 and Neon.
Unfortunately, we didn't come across this scenario anymore, so I can't confirm whether it is still occurring or not.
Comment 6 Cedric Brun CLA 2016-05-17 13:58:02 EDT
Thanks for answering back.

I'll assume it's been resolved in some way. Sirius had quite a lot of changes since then. Feel free to reopen with additional information and thanks for your feedback !