Skip to content
This repository has been archived by the owner. It is now read-only.

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

Closed
kfhoech opened this issue Feb 21, 2018 · 3 comments
Assignees

Comments

@kfhoech
Copy link
Contributor

@kfhoech 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
Copy link
Contributor Author

@kfhoech 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
Copy link
Contributor Author

@kfhoech 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
Copy link
Contributor Author

@kfhoech 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 subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant