Issue by philip-alldredge
Wednesday Aug 09, 2017 at 15:19 GMT
Originally opened as osate/osate-ge#210
While testing refactoring, a NPE is received occasionally. Below is a snipped from the stack trace.
However, the cause of this bug implies an even more critical issue. The bug occurs when the user tries to edit a "live" xtext document and the refactoring processor isn't able to retrieve the element via an xtext resource set using the live scope. The reason this occurs is that under some circumstances, the DirtyStateManager may not contain the dirty state of a resource. This results in the version in the file being used.
It is plausible that under some circumstances, the editor would potentially retrieve an incorrect model resource via the URI and refactor it. I am unaware of other cases this may affect. The editor doesn't use live scoped xtext resource sets or the built-in dirty state manager at this time so the damage is relatively limited. However, in the future, the editor should likely use the built-in capability of xtext.
The issue appears to be in xtext.
Steps to reproduce
- Make whitespace change to text editor.
- Save. This results in a markEditorClean/discardDirtyState. State is now should_update.
- Switch to graphical editor and create a subcomponent. This results in a announceDirtyStateChanged() which attempts to replace. Doesn't add element because replace...
Stack Trace
java.lang.NullPointerException
at org.eclipse.xtext.ui.refactoring.impl.RenameElementProcessor.checkInitialConditions(RenameElementProcessor.java:219)
at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkInitialConditions(ProcessorBasedRefactoring.java:203)
at org.osate.ge.internal.graphiti.features.BoHandlerDirectEditFeature.prepareAndCheck(BoHandlerDirectEditFeature.java:231)
at org.osate.ge.internal.graphiti.features.BoHandlerDirectEditFeature.setValue(BoHandlerDirectEditFeature.java:160)
at org.eclipse.graphiti.internal.command.DirectEditingFeatureCommandWithContext.execute(DirectEditingFeatureCommandWithContext.java:81)
at org.eclipse.graphiti.ui.internal.command.GefCommandWrapper.execute(GefCommandWrapper.java:51)
at org.eclipse.graphiti.ui.internal.editor.EmfOnGefCommand.execute(EmfOnGefCommand.java:54)
at org.eclipse.graphiti.internal.command.GFPreparableCommand2.doExecute(GFPreparableCommand2.java:43)
at org.eclipse.emf.transaction.RecordingCommand.execute(RecordingCommand.java:135)
at org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFCommandOperation.java:119)
at org.eclipse.emf.workspace.AbstractEMFOperation.execute(AbstractEMFOperation.java:150)
at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:516)
at org.eclipse.emf.workspace.impl.WorkspaceCommandStackImpl.doExecute(WorkspaceCommandStackImpl.java:208)
at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:165)
Steps Ahead
- Reproduce issue in an Xtext unit test.
- Report issue to xtext developers.
Wednesday Aug 09, 2017 at 15:19 GMT
Originally opened as osate/osate-ge#210
While testing refactoring, a NPE is received occasionally. Below is a snipped from the stack trace.
However, the cause of this bug implies an even more critical issue. The bug occurs when the user tries to edit a "live" xtext document and the refactoring processor isn't able to retrieve the element via an xtext resource set using the live scope. The reason this occurs is that under some circumstances, the DirtyStateManager may not contain the dirty state of a resource. This results in the version in the file being used.
It is plausible that under some circumstances, the editor would potentially retrieve an incorrect model resource via the URI and refactor it. I am unaware of other cases this may affect. The editor doesn't use live scoped xtext resource sets or the built-in dirty state manager at this time so the damage is relatively limited. However, in the future, the editor should likely use the built-in capability of xtext.
The issue appears to be in xtext.
Steps to reproduce
Stack Trace
Steps Ahead