Bugzilla – Full Text Bug Listing
| Summary: | Exceptions when switching compare editors from detached synchronize view | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Stephan Herrmann <stephan.herrmann> |
| Component: | Compare | Assignee: | Platform-Compare-Inbox <platform-compare-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | christophe.cornu+eclipse, deepakazad, jamesblackburn+eclipse, Olivier_Thomann, owong, pawel.pogorzelski1 |
| Version: | 3.6 | ||
| Target Milestone: | 4.14 M3 | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
(In reply to comment #0) > 5. successively open the compare editor for several changed files, > moving cursor between both toplevel windows, perhaps making little > changes in the compare editor, then double click the next java file. Hi Stephan, I've been trying to reproduce it with CVS and the steps you gave but I failed. Could you elaborate on the last step? What exactly are you doing there? Does it happen each time? What build are you on? (In reply to comment #1) > (In reply to comment #0) > > 5. successively open the compare editor for several changed files, > > moving cursor between both toplevel windows, perhaps making little > > changes in the compare editor, then double click the next java file. > > Hi Stephan, I've been trying to reproduce it with CVS and the steps you gave > but I failed. Could you elaborate on the last step? What exactly are you doing > there? For one, it certainly depends on having this preference checked: [x] Reuse open compare editors when opening comparisons I also tried it with CVS instead of SVN, and yes I could also reproduce. What am I doing? Double click a file in synchronize view -> compare editor opens Double click on another file in synchronize view -> compare editor switches input Unfortunately, I cannot say, which variant actually triggers the bug - keep mouse in window of synchronize view vs. move mouse between windows - make changes in compare editor? - background jobs are working (e.g., workspace build, cvs synchronization) > Does it happen each time? Unfortunately not. Actually right know I succeeded only on the first out of ~10 experiments. Figuring out what makes the difference isn't so easy, because after occurrence of the bug you have to restart Eclipse to get back into a sane state. Perhaps, successfully performing the editor switch once also brings Eclipse into a stable (sane) state? Sorry, last time I was much more successful in reproducing. > What build are you on? I mostly use I20100129-1300, the runtime workbench where I just saw the bug had a org.eclipse.compare checked out and last updated on 2009-12-01. But apparently there were no semantic changes since. Could the firing of window activation events be platform-specific? I'm on Linux-GTK, more specifically: Kubuntu 9.10. I have seen the same set of exceptions (Bug 305113 and Bug 300157). As mentioned in bug 305113, I click the 'Next Difference' icon very fast to just expand the tree. (I now know that there are keyboard shortcuts available to do the same.) I can reproduce this problem 90-100% of the time, I just need to click 'Next Difference' fast enough. Two preferences that need to be set appropriately to reproduce this [x] Reuse open compare editors when opening comparisons [ ] Always run in background Also I see the 'unknown saveable' exception and after that when I close the compare editor I see a NPE. I have never seen this NPE in isolation. java.lang.NullPointerException at org.eclipse.jdt.internal.ui.text.JavaReconciler.uninstall(JavaReconciler.java:341) at org.eclipse.jface.text.source.SourceViewer.unconfigure(SourceViewer.java:692) at org.eclipse.jdt.internal.ui.javaeditor.JavaSourceViewer.unconfigure(JavaSourceViewer.java:357) at org.eclipse.jface.text.source.SourceViewer.handleDispose(SourceViewer.java:745) at org.eclipse.jface.text.source.projection.ProjectionViewer.handleDispose(ProjectionViewer.java:1363) at org.eclipse.jdt.internal.ui.javaeditor.JavaSourceViewer.handleDispose(JavaSourceViewer.java:462) at org.eclipse.jface.text.TextViewer$2.widgetDisposed(TextViewer.java:1798) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:117) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1050) I have tried this with build I20100309-0809. (In reply to comment #2) > Unfortunately not. Actually right know I succeeded only on the first out of > ~10 experiments. Figuring out what makes the difference isn't so > easy, because after occurrence of the bug you have to restart Eclipse > to get back into a sane state. Perhaps, successfully performing the editor > switch once also brings Eclipse into a stable (sane) state? > Sorry, last time I was much more successful in reproducing. After the fix for Bug 300157 Eclipse remains in a sane state. This NPE is fixed as part of Bug 300157.But we have another NPE which I mentioned above. (In reply to comment #0) > java.lang.NullPointerException > at > org.eclipse.ui.texteditor.AbstractTextEditor$ActivationListener.windowActivated(AbstractTextEditor.java:994) > at org.eclipse.ui.internal.Workbench$12.run(Workbench.java:823) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) > at > org.eclipse.ui.internal.Workbench.fireWindowActivated(Workbench.java:821) > at > org.eclipse.ui.internal.WorkbenchWindow$28.shellActivated(WorkbenchWindow.java:3089) > at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:82) > at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) > ... *** Bug 313018 has been marked as a duplicate of this bug. *** *** Bug 272953 has been marked as a duplicate of this bug. *** 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. If you have further information on the current state of the bug, please add it. 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. I personally haven't seen this bug in a long time. I mean it's been a while since I last used SVN but EGit's "Compare with Each Other in Tree" should serve as a similar use case, and *that* I use in a detached window every now and then. If others still see the above exceptions feel free to re-open. |
I'm seeing floods of NPE from CompareEditorInput.run(). I can reproduce the problem using these steps: 1. in a subversive backed project make changes to several java files (should be the same with CVS, I've seen no SVN-specific stack frames) 2. synchronize with repository 3. detach the synchronize view (make it its own toplevel window) 4. and place it on a secondary monitor (shouldn't be needed but that's why I detach it) 5. successively open the compare editor for several changed files, moving cursor between both toplevel windows, perhaps making little changes in the compare editor, then double click the next java file. While the NPE is annoying it may not be the root cause, because shortly before the first NPE I see this: org.eclipse.core.runtime.AssertionFailedException: unknown saveable: org.eclipse.team.ui.synchronize.SaveableCompareEditorInput$InternalResourceSaveableComparison@1cbb860 from part: org.eclipse.compare.internal.CompareEditor@e79610 at org.eclipse.ui.internal.SaveablesList.logWarning(SaveablesList.java:187) at org.eclipse.ui.internal.SaveablesList.addModel(SaveablesList.java:117) at org.eclipse.ui.internal.SaveablesList.addModels(SaveablesList.java:289) at org.eclipse.ui.internal.SaveablesList.handleLifecycleEvent(SaveablesList.java:221) at org.eclipse.compare.internal.CompareEditor.registerSaveable(CompareEditor.java:322) at org.eclipse.compare.internal.CompareEditor.access$4(CompareEditor.java:320) at org.eclipse.compare.internal.CompareEditor$3.run(CompareEditor.java:374) at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:155) at org.eclipse.ui.internal.UISynchronizer$3.run(UISynchronizer.java:158) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3501) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3148) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:173) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:388) at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:507) at org.eclipse.ui.internal.progress.ProgressMonitorJobsDialog.run(ProgressMonitorJobsDialog.java:275) at org.eclipse.ui.internal.progress.ProgressManager$5.run(ProgressManager.java:961) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.progress.ProgressManager.busyCursorWhile(ProgressManager.java:996) at org.eclipse.ui.internal.progress.ProgressManager.busyCursorWhile(ProgressManager.java:971) at org.eclipse.ui.internal.progress.ProgressManager.run(ProgressManager.java:1167) at org.eclipse.compare.internal.CompareContainer.run(CompareContainer.java:80) at org.eclipse.compare.CompareEditorInput.run(CompareEditorInput.java:1229) at org.eclipse.compare.internal.merge.DocumentMerger.doDiff(DocumentMerger.java:435) at org.eclipse.compare.contentmergeviewer.TextMergeViewer.doDiff(TextMergeViewer.java:3277) at org.eclipse.compare.contentmergeviewer.TextMergeViewer.update(TextMergeViewer.java:5001) at org.eclipse.compare.contentmergeviewer.TextMergeViewer.updateContent(TextMergeViewer.java:2849) at org.eclipse.compare.contentmergeviewer.ContentMergeViewer.internalRefresh(ContentMergeViewer.java:783) at org.eclipse.compare.contentmergeviewer.ContentMergeViewer.inputChanged(ContentMergeViewer.java:683) at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:274) at org.eclipse.jdt.internal.ui.compare.JavaMergeViewer.setInput(JavaMergeViewer.java:155) at org.eclipse.compare.CompareViewerSwitchingPane.setInput(CompareViewerSwitchingPane.java:270) at org.eclipse.compare.internal.CompareContentViewerSwitchingPane.setInput(CompareContentViewerSwitchingPane.java:132) at org.eclipse.compare.CompareEditorInput.internalSetContentPaneInput(CompareEditorInput.java:839) at org.eclipse.compare.CompareEditorInput.access$8(CompareEditorInput.java:837) at org.eclipse.compare.CompareEditorInput$11.run(CompareEditorInput.java:777) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.compare.CompareEditorInput.feed1(CompareEditorInput.java:771) at org.eclipse.compare.CompareEditorInput.feedInput(CompareEditorInput.java:749) at org.eclipse.compare.CompareEditorInput.createContents(CompareEditorInput.java:553) at org.eclipse.compare.internal.CompareEditor.createCompareControl(CompareEditor.java:454) at org.eclipse.compare.internal.CompareEditor.access$6(CompareEditor.java:421) at org.eclipse.compare.internal.CompareEditor$4.run(CompareEditor.java:475) at org.eclipse.swt.widgets.Display.timerProc(Display.java:4049) ... This operations completes successfully but the next double click gives the NPE: java.lang.NullPointerException at org.eclipse.ui.texteditor.AbstractTextEditor$ActivationListener.windowActivated(AbstractTextEditor.java:994) at org.eclipse.ui.internal.Workbench$12.run(Workbench.java:823) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.Workbench.fireWindowActivated(Workbench.java:821) at org.eclipse.ui.internal.WorkbenchWindow$28.shellActivated(WorkbenchWindow.java:3089) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:82) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) ... From here it may be tricky to get the workbench back into a sane state. All I could see in the debugger is that the windowActivated event uses an old CompareEditorInput, *not* the one being initialized in another (waiting) thread from Object.wait(long) line: not available [native method] Semaphore.acquire(long) line: 43 UISynchronizer.syncExec(Runnable) line: 168 Display.syncExec(Runnable) line: 4225 Utilities.firePropertyChange(ListenerList, PropertyChangeEvent) line: 166 Utilities.firePropertyChange(ListenerList, Object, String, Object, Object) line: 140 ModelCompareEditorInput(CompareEditorInput).setTitle(String) line: 421 ModelCompareEditorInput(SaveableCompareEditorInput).prepareInput(IProgressMonitor) line: 241 ModelCompareEditorInput(CompareEditorInput).run(IProgressMonitor) line: 482 CompareUIPlugin.prepareInput(CompareEditorInput, IProgressMonitor) line: 548 CompareEditor$2.run(IProgressMonitor) line: 348 Worker.run() line: 55 This can be worked around by always closing the compare editor before double clicking the next file.