Community
Participate
Working Groups
I am not sure if this is a problem with MultiEditor, AbstractTextEditor or my implementation. But looking at what's happening, I cannot see how I can contribute to this, or work around this. 1) Create an multi pane editor implmentation based on AbstractMultiEditor. 2) In my implementation, the multi editor returns a sashform as the main composite 3) Each of the sash form contains a view form. The view form is the parent of the inner editor. 4) When the Multi-editor is opened, each side of the editor is opened on a different IFileEditorInput. 5) While the editor is opened, I dragged and dropped one of the file opened by the multi editor to another folder. -> This will cause the following exception to be logged: org.eclipse.core.runtime.AssertionFailedException: unknown saveable: org.eclipse.ui.texteditor.AbstractTextEditor$TextEditorSavable@45f045f from part: com.ibm.streams.studio.splmmeditor.ui.internal.splmm.InternalSplmmEditor@79ca79ca at org.eclipse.ui.internal.SaveablesList.logWarning(SaveablesList.java:187) at org.eclipse.ui.internal.SaveablesList.removeModel(SaveablesList.java:166) at org.eclipse.ui.internal.SaveablesList.removeModels(SaveablesList.java:270) at org.eclipse.ui.internal.SaveablesList.handleLifecycleEvent(SaveablesList.java:240) at org.eclipse.ui.texteditor.AbstractTextEditor.doSetInput(AbstractTextEditor.java:4036) at org.eclipse.ui.texteditor.StatusTextEditor.doSetInput(StatusTextEditor.java:217) at org.eclipse.ui.texteditor.AbstractDecoratedTextEditor.doSetInput(AbstractDecoratedTextEditor.java:1444) at org.eclipse.ui.editors.text.TextEditor.doSetInput(TextEditor.java:169) at org.eclipse.xtext.ui.editor.XtextEditor.doSetInput(XtextEditor.java:149) at com.ibm.streams.studio.spleditor.ui.SPLEditor.doSetInput(SPLEditor.java:143) at org.eclipse.ui.texteditor.AbstractTextEditor.setInputWithNotify(AbstractTextEditor.java:4120) at org.eclipse.ui.texteditor.AbstractTextEditor.setInput(AbstractTextEditor.java:4142) at org.eclipse.ui.texteditor.AbstractTextEditor$7.run(AbstractTextEditor.java:528) at org.eclipse.ui.texteditor.AbstractTextEditor$ElementStateListener.execute(AbstractTextEditor.java:597) at org.eclipse.ui.texteditor.AbstractTextEditor$ElementStateListener.elementMoved(AbstractTextEditor.java:558) at org.eclipse.ui.texteditor.AbstractDocumentProvider.fireElementMoved(AbstractDocumentProvider.java:741) at org.eclipse.ui.editors.text.FileDocumentProvider.handleElementMoved(FileDocumentProvider.java:879) I debugged this problem, and found the following: 1) When the multi-editor is opened, the two inner editor's #doSetInput will be called. Eventually, it will call AbstractTextEditor#doSetInput. 2) At creation, fSaveable is still null, therefore mustSendLifeCycleEvent is set to false. As a result, at the end of the doSetInput method, the SaveableLifeCycleEvent.POST_OPEN is never fired, and the model is not saved in SaveableList. 3) When the file is moved, the text editor's document provider detects that the file has been moved, and will call doSetInput again. 4) In this call, because fSaveable is not null and also we have an old editor input to remove, we fire off the SaveableLifecycleEvent.POST_CLOSE event. The listener, which is the SaveableList, cannot find the model because it was never added, and logs the exception. 5) Also in this call, mustSendLifeCycleEvent is set to true, and the model is now saved in the SaveableList at the end when SaveableLifeCycleEvent.POST_OPEN is fired. 6) The SaveableList uses the editor as the key to the model, and both the editor and the saveable model are saved in the SaveableList 7) If I close the multiEditor now, the workbench detects that the editor is closed and will fire the SaveableLifeCycleEvent.POST_CLOSE event, in an attempt to clean up the SaveableList. However, when this is called, the workbench only knows about the mult-editor, and will use the multiEditor as the key to remove the saveable models. It does not know about the inner editors, and the models for the inner editors are left behind in the SaveableList.
See bug 212244 comment 8.
(In reply to comment #1) > See bug 212244 comment 8. Since this is leaking the editor, and can be quite a big leak, can you please investigate if this can be fixed in 3.6.2? Thanks!
See http://www.eclipse.org/eclipse/development/plans/freeze_plan_3_6_2.php - only critical bugs would still be fixed on the 3.6.2 stream given how close we are to the release. Do you have a scenario where unsaved changes would be lost? Leaks caused by moving files doesn't sound scary enough for me to risk a code change right before the 3.6.2 release.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.