Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running 'Check Realizability' analysis causes Xtext exception (and possible crash) #79

Closed
kfhoech opened this Issue Feb 21, 2018 · 3 comments

Comments

Projects
None yet
1 participant
@kfhoech
Copy link
Contributor

kfhoech commented Feb 21, 2018

Running 'Check Realizability' analysis causes an IllegalStateException in Xtext errors as follows:

java.lang.IllegalStateException: The resource should have no more than one root element, but: [org.osate.aadl2.impl.AadlPackageImpl@2f336e00 (name: Top_System), org.osate.aadl2.impl.SystemImplementationImpl@2f51cb99 (name: Top_System.wrapper) (noPrototypes: false, noAnnexes: false, noProperties: false) (derivedModes: false, noFlows: false, noModes: false) (noSubcomponents: false, noConnections: false, noCalls: false)]
at org.eclipse.xtext.resource.DerivedStateAwareResource.installDerivedState(DerivedStateAwareResource.java:239)
at org.eclipse.xtext.resource.DerivedStateAwareResource.getContents(DerivedStateAwareResource.java:97)
at org.eclipse.emf.ecore.util.EcoreUtil.getAllContents(EcoreUtil.java:1178)
at org.eclipse.xtext.linking.lazy.LazyLinkingResource.resolveLazyCrossReferences(LazyLinkingResource.java:125)
at org.eclipse.xtext.EcoreUtil2.resolveLazyCrossReferences(EcoreUtil2.java:498)
at org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.postParse(XtextDocumentReconcileStrategy.java:175)
at org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.doReconcile(XtextDocumentReconcileStrategy.java:153)
at org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.reconcile(XtextDocumentReconcileStrategy.java:67)
at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.doRun(XtextReconciler.java:449)
at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.access$3(XtextReconciler.java:429)
at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler$1.process(XtextReconciler.java:363)
at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler$1.process(XtextReconciler.java:1)
at org.eclipse.xtext.util.concurrent.IUnitOfWork$Void.exec(IUnitOfWork.java:37)
at org.eclipse.xtext.resource.OutdatedStateManager.exec(OutdatedStateManager.java:91)
at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.modify(XtextDocument.java:428)
at org.eclipse.xtext.ui.editor.model.XtextDocument.internalModify(XtextDocument.java:162)
at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.run(XtextReconciler.java:360)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)

This can result in an infinite series repeated errors and essentially hang the UI because Xtext cannot complete its work.

Occurs on both Windows and Linux. (Given the nature of the error, that's expected.)

Duplicated with clean checkout of develop branch at hash 2af6b96.

@kfhoech

This comment has been minimized.

Copy link
Contributor Author

kfhoech commented Feb 21, 2018

The problem here seems to be that for Realizability analysis, the VerifyHandler creates an ephemeral system implementation for the selected system type and then applies the OSATE buildInstanceModelFile for the ephemeral instance. The combination of an otherwise unlinked system implementation and instantiation must violate an Xtext API rule.

This issue also affects the MATLAB codegen as it also uses the same combination of ephemeral implementation and instantiation as does Realizability.

@kfhoech

This comment has been minimized.

Copy link
Contributor Author

kfhoech commented Feb 21, 2018

Looks like one of two choices to solve this...

  1. Build (and maintain) a parallel AGREE program builder that works on system types (rather than system instances) and further handles all of the model instantiation rules. This is a huge effort and a large maintenance burden to keep things in sync.
  2. In sort of an ugly means of getting the ephemeral system implementation, we, using a transactional editing domain, generate a new package file with an unlikely name (perhaps with a GUID and then an iterating on new names until we find one that is not in use), generating in the ephemeral package file an empty system implementation of the given system type, saving the ephemeral package file, passing the generated system implementation to the remainder of the analysis (including instantiation), and then cleaning up the generated instantation file and the ephemeral package file.

Looks like the latter is the way to go...

@kfhoech

This comment has been minimized.

Copy link
Contributor Author

kfhoech commented Feb 26, 2018

Fixed with pull request 80. #80

@kfhoech kfhoech closed this Feb 26, 2018

@kfhoech kfhoech added the v2.3.3 label Jul 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.