Community
Participate
Working Groups
build I20090203-1200 1) checkout org.eclipse.jdt.core 2) add a type org.eclipse.jdt.core.ZZZ.java 3) select org.eclipse.jdt.core and synchronize with the repository 4) from the synchronize view open ZZZ.java in compare editor 5) in the synchronize view select ZZZ.java and do 'Override and Update' 6) do ctrl+shift+T and type ZZZ ZZZ.java appear 7) try to open ZZZ.java an error window appear The deleted type is also still visible in the package explorer The problem does not occur if i do not open ZZZ.java in compare editor. The problem is caused by a workingcopy of ZZZ.java which was not discarded.
>5) in the synchronize view select ZZZ.java and do 'Override and Update' >6) do ctrl+shift+T and type ZZZ How long did you wait between these steps? If the update took some time (or was even blocked due to other jobs) then it is expected that the indexer still finds the type but at the time you open it, you get an exception.
I wait more than 60sec and i do nothing before do ctrl+shift+T.
And you did not use that type before i.e. it is not in the Open Type history?
Does it work if you simply delete the CU?
I did not use that type before. This type is not in the Open Type history. It work correctly when i delete the CU from the package explorer. I reproduce the problem only if i open the type in the compare editor.
OK, I see the problem: the compare editor does not react on the deletion of the CU and as a result we have a left-over working copy. 1. compare a CU with a previous state 2. delete the CU ==> CU remains in Package Explorer and can no longer be removed. Either the compare editor needs to be automatically closed or at least the working copy be disposed. NOTE: a similar leak will happen once we switch to enhanced text compare.
This is 'major' as there's no way except restart to get rid of the dangling working copy. The wrapped editor would handle the close itself but the problem is that org.eclipse.jdt.internal.ui.compare.JavaMergeViewer.CompilationUnitEditorAdapter.getEditorInput() returns 'null.
The JavaMergeViewer.CompilationUnitEditorAdapter.getEditorInput() returns null due to the check in JavaMergeViewer.isInputValid(IEditorInput) which verifies if a file editor input is accessible. When deleting a file, the check fails and returns null. Removing the check reveals another problem: in reaction to file deletion the inner editor does close the compare editor[1] as Dani said, but soon after the TextMergeViewer attempts to respond to the same file deletion by refreshing the viewer(s)[2]. This leads to "widget is disposed" exception. [1] org.eclipse.ui.texteditor.AbstractTextEditor.close(boolean) [2] org.eclipse.compare.contentmergeviewer.TextMergeViewer.ContributorInfo.resetDocument(), the checkState() method returns true, the "widget is disposed" exception(s) is thrown a little bit later, ie the editor close[1] happens in the meantime
Created attachment 125238 [details] Patch v01 The patch contains two changes: * the JavaMergeViewer.isInputValid(IEditorInput) check now returns true even for a deleted file. I haven't observed any harmful side effects so far. * the first change allow us to close the wrapped editor on a file deletion. However the fix disconnects the editor input from the working copy manager instead of closing the editor. Comments are welcome.
Created attachment 125239 [details] mylyn/context/zip
The fix does not work. Most likely because the fDocumentKey which is used to return the input is set to 'null' in TextMergeViewer.ContributorInfo.disconnect(). If the compare editor wants to stay open then we must avoid to run into the CU editors close() method in order to avoid widgetDisposed errors like you already described in comment 8 and handle the issue either by overriding TextMergeViewer.updateContent(Object, Object, Object) or by opening up TextMergeViewer.disconnect(ContributorInfo) and override it in JTMV.
Created attachment 126574 [details] Proposal v02 The change in ConentMergeViewer prevents "widget is disposed" errors. For the JavaMergeViewer part I tried make more use of natural life-cycle of CU editor, that's why I didn't followed Dani suggestions from comment 11 and stick to the editor input (removed getEditorInput from CUEA). The fix works pretty good for the case from comment 0, since Compare Editor closes itself here, because there are no diffs when we decide to override and update an outgoing addition (both sides become empty). Closing CE disposes nested CU editors as well so there seems to be no dangling CUs left. However there is at least one scenario where it doesn't work: 1. Share a project 2. Edit a CU file 3. Sync with HEAD 4. Open Compare Editor for the outgoing change 5. Delete the file from Package Explorer => Sometimes NPE is thrown from OperationHistoryActionHandler.java:123, undo won't work after that 6a. Click on the CE => NPE(s) will be thrown, missing document provider 6b. Restore the file from repository and open it => The change you made in 2 will be there. This worries me the most, did I miss something in my own implementation of close(boolean)? I guess overridding close(boolean) method is not a bad idea, but the question is what should I put there? Or is this completely wrong?
> 5. Delete the file from Package Explorer > => Sometimes NPE is thrown from OperationHistoryActionHandler.java:123, undo > won't work after that That's bug 258679 (but that should only affect the undo stack).
> 6b. Restore the file from repository and open it > => The change you made in 2 will be there. I've just checked it on 3.4 and 3.5M3 (prior enhanced-Java-compare changes) and it works the same there, so it's not a regression, but still an issue imo => bug 266339.
Created attachment 126869 [details] Patch v03 > 6a. Click on the CE > => NPE(s) will be thrown, missing document provider Disposing the document provider was a silly thing to do.
(In reply to comment #12) > Proposal v02 > The change in ContentMergeViewer prevents "widget is disposed" errors. This has been addressed in bug 221583.
Committed JDT part to HEAD with one minor change: in close(boolean save) I call getDocumentProvider().disconnect(getEditorInput());
Verified in I20090311-0100.
