Comment 1 Carolyn MacLeod 2011-10-18 15:15:19 EDT

I got this also. Sorry, not sure what I did immediately before. Something in Git Repo perspactive, I think. Eventually I had to restart eclipse because I could not do basic things like run a snippet. Please check out ContentMergeViewer line 121 and see what could be causing null pointer exception.

java.lang.NullPointerException
	at org.eclipse.compare.contentmergeviewer.ContentMergeViewer$ContentMergeViewerLayout.layout(ContentMergeViewer.java:121)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1263)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1270)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1270)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1270)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1270)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1270)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1270)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1270)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1270)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1249)
	at org.eclipse.swt.widgets.Composite.setLayoutDeferred(Composite.java:1086)
	at org.eclipse.swt.widgets.Display.runDeferredLayouts(Display.java:4189)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3747)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:972)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:888)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:90)
	at org.eclipse.ui.internal.Workbench$3.run(Workbench.java:565)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:520)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:352)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:624)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:579)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1431)

Comment 2 Remy Suen 2011-12-12 15:46:21 EST

Just got into this state. Worked around the problem by spawning a new workbench window and closing my buggy one.

Comment 3 Paul Webster 2011-12-13 09:23:16 EST

*** Bug 366455 has been marked as a duplicate of this bug. ***

Comment 4 Remy Suen 2012-01-12 14:51:32 EST

*** Bug 368413 has been marked as a duplicate of this bug. ***

Comment 5 Remy Suen 2012-01-31 11:59:46 EST

*** Bug 370244 has been marked as a duplicate of this bug. ***

Comment 6 Paul Webster 2012-03-06 11:43:31 EST

*** Bug 373398 has been marked as a duplicate of this bug. ***

Comment 7 Malgorzata Janczarska 2012-08-20 08:02:49 EDT

*** Bug 387528 has been marked as a duplicate of this bug. ***

Comment 8 Eric Moffatt 2012-08-23 14:28:30 EDT

Paul, given the number of DUP's do you think we should have someone look at this earlier (i.e. 4.2.2) ?

Comment 9 David Rees 2012-10-19 13:20:41 EDT

It certainly feels like its priority should be higher since it breaks a lot more than just compare. It seems to generally break opening Java files from various places including the debugger stack (see 370630).

Comment 10 Karsten Pagel 2013-01-09 02:59:43 EST

Hi, same problem here.

Don't know if its exactly the same problem, some linenumbers changed:

Stacktrace:
java.lang.NullPointerException
	at org.eclipse.compare.contentmergeviewer.ContentMergeViewer$ContentMergeViewerLayout.layout(ContentMergeViewer.java:121)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1570)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1576)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1576)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1576)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1576)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1576)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1576)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1576)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1576)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1576)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1576)
	at org.eclipse.swt.widgets.Composite.setLayoutDeferred(Composite.java:1426)
	at org.eclipse.swt.widgets.Display.runDeferredLayouts(Display.java:3578)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3166)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1029)
[...]

Environment:
eclipse.buildId=M20120914-1800
java.version=1.6.0_35
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE
Framework arguments:  -product org.eclipse.epp.package.java.product
Command-line arguments:  -os linux -ws gtk -arch x86_64 -product org.eclipse.epp.package.java.product


Sometime i can work for some hours till the problem occurs, but sometimes it happens just a few minutes after startup. Once occured it is almost impossible to work with eclipse. most of the times you open an editor (java-editor, xml-editor, compare-view) its just empty and no content is displayed. after double-clicking on the tab of the editor (maximize view) the content is displayed...

Comment 11 Ed Willink 2013-03-21 13:14:22 EDT

Just seen this in M6 after trying to open Workspace file from the GIT staging view.

Most of the new M6 errors seem benign. This one gives a grey screen editor. Eclipse restart necessary no doubt.

Comment 12 Dani Megert 2013-04-10 10:01:54 EDT

*** Bug 405359 has been marked as a duplicate of this bug. ***

Comment 13 Ed Willink 2013-06-23 11:57:46 EDT

Just seen this in RC4.

I was happily debugging, advanced to a breakpoint, and got a pop up telling me I had an NPE, and grey screen where I'm trying to debug.

....

While checking that the stack trace is exactly the same, I find that I am no longer able to display the Event Details from the Error Log.

Perhaps this bug is actually a symptom of an Eclipse session suffering from a memory leak. My session had perhaps been going for 10 hours.

Comment 14 David M. Karr 2013-07-23 17:13:35 EDT

Today I'm seeing the stack trace that follows this in my log when I try to view any Java source file (Javascript ones aren't failing).  I guess I'm going to try restarting Eclipse (STS 3.3.0).

!ENTRY org.eclipse.ui 4 0 2013-07-23 14:11:03.905
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.NullPointerException
	at org.eclipse.compare.contentmergeviewer.ContentMergeViewer$ContentMergeViewerLayout.layout(ContentMergeViewer.java:121)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1291)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1298)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1277)
	at org.eclipse.swt.widgets.Composite.setLayoutDeferred(Composite.java:1088)
	at org.eclipse.swt.widgets.Display.runDeferredLayouts(Display.java:4194)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1426)

Comment 15 David M. Karr 2013-07-23 17:20:05 EDT

Note that I was also seeing this for pom.xml files.  After I restarted Eclipse, this went away.

Comment 16 David M. Karr 2013-07-23 17:20:26 EDT

Note that I was also seeing this for pom.xml files.  After I restarted Eclipse, this went away.

Comment 17 Helge Priva 2013-07-31 07:51:34 EDT

If you have this problem please vote for this bug (above).

Comment 18 Helge Priva 2013-07-31 08:04:23 EDT

Could someone insert Remy Suen's nice workaround here more prominently: "Worked around the problem by spawning a new workbench window and closing my buggy one."
That is much much faster than restarting Eclipse.

Comment 19 Francis Upton IV 2013-07-31 11:01:36 EDT

*** Bug 413660 has been marked as a duplicate of this bug. ***

Comment 20 Francis Upton IV 2013-07-31 11:02:05 EDT

Moving to major as a lot of people seem to hit this problem.

Comment 21 David Clemens 2013-11-01 10:24:03 EDT

I am getting the same error frequently but not always when I click on a java file to open it in the editor, which shows a blank grey screen.  I can sometimes get the contents to appear by clicking the java file a second time.  I also get this error sometimes using Open Declaration and switching to that editor buffer.  Note that the editor may already have been open, and that it may have displayed correctly a few times, but still suddenly hit this problem.

I have also been able to "refresh" the editor by full-screening it and then "Restore"ing it back down.

Obviously, this is major.

(Kepler on Windows 7, Java 7)

Comment 22 Ed Willink 2013-11-01 11:50:01 EDT

This was fixed in M1 and broken again in M2.

Bug 419086

Comment 23 David Clemens 2013-11-01 11:59:48 EDT

I should add, I was not working directly with the Compare editor when these errors happened, but I had been working with it earlier in the session, just in case it leaves behind bad state.

Comment 24 Paul Webster 2013-12-03 13:17:39 EST

*** Bug 423047 has been marked as a duplicate of this bug. ***

Comment 25 Leo Dos Santos 2014-02-13 16:52:46 EST

I've been running into this a lot over the last couple of weeks. The only hint I have is that I've been making increased use of Mylyn Reviews, which uses the comparison editor heavily.

Comment 26 Szymon Ptaszkiewicz 2014-02-14 02:35:28 EST

*** Bug 427596 has been marked as a duplicate of this bug. ***

Comment 27 Szymon Ptaszkiewicz 2014-02-14 02:41:31 EST

*** Bug 334404 has been marked as a duplicate of this bug. ***

Comment 28 Szymon Ptaszkiewicz 2014-02-14 02:42:33 EST

*** Bug 427764 has been marked as a duplicate of this bug. ***

Comment 29 Szymon Ptaszkiewicz 2014-02-14 03:08:48 EST

Bug 349497 contains some analysis with potential steps to reproduce.

Comment 30 Endre Kovács 2014-02-25 08:21:31 EST

occurs on OS X as well. 
This is very much a pain in the...

(Eclipse Modeling Tools
Version: Kepler Service Release 1
Build id: 20130919-0819

java.version=1.7.0_45
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
OS X maverics
)

Comment 31 Eric Moffatt 2014-02-26 11:05:15 EST

*** Bug 349497 has been marked as a duplicate of this bug. ***

Comment 32 Eric Moffatt 2014-02-26 11:13:10 EST

Any hints on how to cause this to happen would be a great help...from my comments on Bug 349497 there is a suspicion that the MinMax handling might be part of the problem.

To the folks seeing this issue...

Do you regularly change the maximized state when doing compares ? (i.e. maximizing the editor area to make room...)

If you do are you likely to switch in and out of the maximized state as part of your workflow ? (i.e. not normally maximized but do during compares...).

I use the Git Staging view to do my compares but I'm presuming that it uses the standard compare editor and I haven't seen this for a couple of years. The number of DUPs does indicate that there's some sort of issue though (race condition?).

Comment 33 Ed Willink 2014-02-26 11:36:51 EST

(In reply to Eric Moffatt from comment #32)
> Any hints on how to cause this to happen would be a great help

In comment 13, I kind of retracted my 'me too' on the grounds that it looked remarkably like yet another symptom of the memory leak problem. 

So perhaps another relevant question is whether this ever happens when Eclipse is relatively fresh from a restart.

Comment 34 Leo Dos Santos 2014-02-27 14:11:55 EST

(In reply to comment #32)
> Any hints on how to cause this to happen would be a great help...from my
> comments on Bug 349497 there is a suspicion that the MinMax handling might be
> part of the problem.
> 
> To the folks seeing this issue...
> 
> Do you regularly change the maximized state when doing compares ? (i.e.
> maximizing the editor area to make room...)
> 
> If you do are you likely to switch in and out of the maximized state as part of
> your workflow ? (i.e. not normally maximized but do during compares...).

Yes, that more or less describes my work flow. I'll often max the editor pane when I'm looking at a compare editor or whenever I need to have two editors side-by-side, and I'll restore the editor pane it whenever I'm done with that task. I also see the behaviour described in comment #10, where editors are blank after this bug has been triggered. Min/maxing the blank editor will refresh the content.

Comment 35 Stephan Herrmann 2014-05-08 11:16:45 EDT

Luna M7:

Floods of:

java.lang.NullPointerException
	at org.eclipse.compare.contentmergeviewer.ContentMergeViewer$ContentMergeViewerLayout.layout(ContentMergeViewer.java:121)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1652)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1658)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1658)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1658)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1658)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1658)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1658)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1658)
	at org.eclipse.swt.widgets.Composite.layout(Composite.java:1004)
	at org.eclipse.swt.custom.CTabFolder.runUpdate(CTabFolder.java:3755)
	at org.eclipse.swt.custom.CTabItem.getBounds(CTabItem.java:149)
	at org.eclipse.swt.custom.CTabFolder.onPaint(CTabFolder.java:1993)
	at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.java:289)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
	at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4462)

Looking into the log maybe this was the first exception starting corruption:

Caused by: java.lang.IllegalArgumentException
        at org.eclipse.core.runtime.ListenerList.remove(ListenerList.java:155)
        at org.eclipse.compare.structuremergeviewer.DiffNode.removeCompareInputChangeListener(DiffNode.java:124)
        at org.eclipse.team.ui.synchronize.SaveableCompareEditorInput.handleDispose(SaveableCompareEditorInput.java:209)
        at org.eclipse.compare.CompareEditorInput$4.widgetDisposed(CompareEditorInput.java:578)
        at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:123)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)

        at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4462)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1393)
        at org.eclipse.swt.widgets.Widget.release(Widget.java:1201)
        at org.eclipse.swt.widgets.Control.release(Control.java:3796)
        at org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:1360)
        at org.eclipse.swt.widgets.Widget.release(Widget.java:1204)
        at org.eclipse.swt.widgets.Control.release(Control.java:3796)
        at org.eclipse.swt.widgets.Widget.dispose(Widget.java:472)
        at org.eclipse.compare.internal.CompareEditor.doSetInput(CompareEditor.java:283)
        at org.eclipse.compare.internal.CompareEditor.setInput(CompareEditor.java:254)
        at org.eclipse.compare.internal.CompareUIPlugin$1.run(CompareUIPlugin.java:552)
        at org.eclipse.compare.internal.CompareUIPlugin.syncExec(CompareUIPlugin.java:1419)
        at org.eclipse.compare.internal.CompareUIPlugin.internalOpenEditor(CompareUIPlugin.java:573)
        at org.eclipse.compare.internal.CompareUIPlugin.openEditorInBackground(CompareUIPlugin.java:543)
        at org.eclipse.compare.internal.CompareUIPlugin.openCompareEditor(CompareUIPlugin.java:532)
        at org.eclipse.compare.CompareUI.reuseCompareEditor(CompareUI.java:199)
        at org.eclipse.compare.CompareUI.reuseCompareEditor(CompareUI.java:180)
        at org.eclipse.egit.ui.internal.CompareUtils.openInCompare(CompareUtils.java:284)
        at org.eclipse.egit.ui.internal.CompareUtils.compareWorkspaceWithRef(CompareUtils.java:426)
        at org.eclipse.egit.ui.internal.CompareUtils.compare(CompareUtils.java:547)
        at org.eclipse.egit.ui.internal.actions.CompareWithIndexActionHandler.execute(CompareWithIndexActionHandler.java:47)
        at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:294)
        at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
        at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source)

Next was:

java.lang.NullPointerException
        at org.eclipse.jdt.internal.ui.text.JavaReconciler.uninstall(JavaReconciler.java:345)
        at org.eclipse.jface.text.source.SourceViewer.unconfigure(SourceViewer.java:711)
        at org.eclipse.jdt.internal.ui.javaeditor.JavaSourceViewer.unconfigure(JavaSourceViewer
.java:393)
        at org.eclipse.jface.text.source.SourceViewer.handleDispose(SourceViewer.java:764)
        at org.eclipse.jface.text.source.projection.ProjectionViewer.handleDispose(ProjectionVi
ewer.java:1336)
        at org.eclipse.jdt.internal.ui.javaeditor.JavaSourceViewer.handleDispose(JavaSourceView
er.java:502)
        at org.eclipse.jface.text.TextViewer$2.widgetDisposed(TextViewer.java:1806)
        at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:123)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4462)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1397)
        at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1182)
        at org.eclipse.swt.custom.StyledText.handleDispose(StyledText.java:5852)

Followed by the flood of the first mentioned exception.

At this point the IDE ceased rendering all kinds of things in various views.

What I was doing: 

- In the background a long running JUnit plugin test (hence I could not restart at the first occurrence - otherwise I see no connection)

- I had been using various compare editors from git staging and git history, but since compare editors tend to busy the CPU I do have the habit of closing all compare editors when no longer used. So when the flood of exceptions occurred I had no compare editor open. The NPE obviously occurred in a leaked instance that has been partially disposed.

- I was trying to open some editor, I thing by double clicking on a search result, but I can't even see the search result any more to help me remember (it's simply not rendered anymore, all views in that stack are empty / gray, and each tab is rendered only when the mouse moves over the tab.


Theory: exceptions during dispose escalate, in that half-dispose instances still linger around. Whenever that zombie receives any event further exceptions escalate the situation until s.t. in the platform itself starts to give up.

In my experience, when working with compare editors on a regular basis, this bug may not occur every day, but then it may happen in rather short intervals. It is surely one of the most frequent bugs in my day-to-day development, and has been for several years. Sometimes, it's just an NPE error dialog and things keep working mostly OK, but sometimes it really escalates...

(In reply to Eric Moffatt from comment #32)
> Do you regularly change the maximized state when doing compares ? (i.e.
> maximizing the editor area to make room...)

Yes. Either maximize compare editor, or minimize one or more other stacks.

> If you do are you likely to switch in and out of the maximized state as part
> of your workflow ? (i.e. not normally maximized but do during compares...).

Yes.

> I use the Git Staging view to do my compares but I'm presuming that it uses
> the standard compare editor and I haven't seen this for a couple of years.
> The number of DUPs does indicate that there's some sort of issue though
> (race condition?).

Git staging view is the most typical point for me launching the compare editor, but I have many workflows leading to a compare editor, actually.

While I understand that the initial exception may be difficult to fix without deterministic steps, wouldn't it be possible to just (blindly) add extra checks into each of the subsequent exception locations to prevent the error from escalating?

Comment 36 Stephan Herrmann 2014-05-08 11:44:40 EDT

Regarding the memory leak: I'm uploading a heap dump from the corrupted state to http://build.eclipse.org/tools/objectteams/bug348429/heap.zip (130MB zip).

From looking at this dump I'd suspect the leak to be via one of the listeners lists. MergeSourceViewer (while no longer in use) is referenced from
- Object[79]
  - listeners : ListenerList
    - listeners : DefaultOperationHistory
      - many incoming links named
          history, fHistory, operationHistory, fOperationHistory
        Reference from OperationHistoryFactory seems to connect to GC root.

HTH

Comment 37 Stephan Herrmann 2014-05-08 13:33:50 EDT

(In reply to Stephan Herrmann from comment #36)
> Regarding the memory leak: I'm uploading a heap dump from the corrupted
> state to http://build.eclipse.org/tools/objectteams/bug348429/heap.zip
> (130MB zip).

upload has finished ...

Comment 38 Stephan Herrmann 2014-05-20 14:32:31 EDT

I can't remember a day when I didn't have to restart Eclipse at least once, because this bug completely borked the IDE.

Comment 39 Stephan Herrmann 2014-05-20 15:29:45 EDT

Dani Megert <daniel_megert@ch.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |major

Mh, I thought the severity is used to track the impact it has on reporters,
and the engineering evaluation of importance is via the priority flag???

For me as a user it has always been a major annoyance and has recently escalated to be the #1 problem that completely interrupts my flow of work.

Comment 40 Dani Megert 2014-05-20 15:36:02 EDT

(In reply to Stephan Herrmann from comment #39)
> Dani Megert <daniel_megert@ch.ibm.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Severity|critical                    |major
> 
> Mh, I thought the severity is used to track the impact it has on reporters,
> and the engineering evaluation of importance is via the priority flag???

We follow the formerly available bugzilla rules, see bug 367944.

Comment 41 Stephan Herrmann 2014-05-20 15:45:17 EDT

https://wiki.eclipse.org/Bug_Reporting_FAQ#What_is_the_difference_between_Severity_and_Priority.3F

says "Severity is assigned by a user and describes the level of impact the bug is having on them"

Being forced to restart implies loss of data => critical

BTW, just now it took only 45 min until the UI was broken up after a fresh restart: various elements of the UI stop rendering (tabs, editor content etc.), re-appear only sporadically on mouse over, until finally no more editors can be created.

To me that kind of behaviour looks like a stop-ship bug.

Comment 42 Dani Megert 2014-05-20 16:00:28 EDT

(In reply to Stephan Herrmann from comment #41)
> Being forced to restart implies loss of data => critical

No. Loss of data is loss of data. Restart is not. Or did you really loose real data?


> To me that kind of behaviour looks like a stop-ship bug.

The bug is 3 years old and did not stop the shipping nor produce useful steps that would allow us to fix it.

Comment 43 Stephan Herrmann 2014-05-20 16:17:37 EDT

(In reply to Dani Megert from comment #42)
> (In reply to Stephan Herrmann from comment #41)
> > Being forced to restart implies loss of data => critical
> 
> No. Loss of data is loss of data. Restart is not. Or did you really loose
> real data?

I typically mean what I write. Yes.
 
> > To me that kind of behaviour looks like a stop-ship bug.
> 
> The bug is 3 years old and did not stop the shipping nor produce useful
> steps that would allow us to fix it.

I uploaded a heap dump of the broken state indicating the leak that is suspected to be the root cause. Any suggestions what else I should do? Help me help you!

My personal feeling is that each exception pasted into this bug demonstrates a link in a chain of escalations. At each step a null check could possible stop the original problem from escalating to the critical state.

Do you see any blocking reason not to insert null checks right now for RC2?
You have the line numbers.

Comment 44 Dani Megert 2014-05-20 16:26:31 EDT

(In reply to Stephan Herrmann from comment #43)
> (In reply to Dani Megert from comment #42)
> > (In reply to Stephan Herrmann from comment #41)
> > > Being forced to restart implies loss of data => critical
> > 
> > No. Loss of data is loss of data. Restart is not. Or did you really loose
> > real data?
> 
> I typically mean what I write. Yes.

Can you explain what data you lost and how? The bug is about the merge viewer, so, I would expect that any state can be saved before manually restarting.

  
> Any suggestions what else I should do? Help
> me help you!

Yes please :-). Post steps that allow us to reproduce the problem and then fix it.


> My personal feeling is that each exception pasted into this bug demonstrates
> a link in a chain of escalations. At each step a null check could possible
> stop the original problem from escalating to the critical state.
> 
> Do you see any blocking reason not to insert null checks right now for RC2?
> You have the line numbers.

We already have enough places with "fixes" that then prevent us from finding and fixing the real problem.

Comment 45 Stephan Herrmann 2014-05-20 16:48:03 EDT

(In reply to Dani Megert from comment #44)
> > Any suggestions what else I should do? Help
> > me help you!
> 
> Yes please :-). Post steps that allow us to reproduce the problem and then
> fix it.

That's not helping me.

I'll rather go back to fixing compiler bugs.

Comment 46 Dani Megert 2014-06-03 11:28:01 EDT

(In reply to Stephan Herrmann from comment #45)
> (In reply to Dani Megert from comment #44)
> > > Any suggestions what else I should do? Help
> > > me help you!
> > 
> > Yes please :-). Post steps that allow us to reproduce the problem and then
> > fix it.
> 
> That's not helping me.

I know.

I tried for a full hour to reproduce the problem, invoking heavy open/close scenarios but not luck. As you can see from the various stack traces, we would have to add band-aid at various places without being sure no new bugs follow up.

The root cause seems to be a specific close scenario of the compare editor, so, everyone on this bug please try to remember what you've done when you see this again and post it here. Thanks!

Comment 47 Stephan Herrmann 2014-06-03 18:19:57 EDT

(In reply to Dani Megert from comment #46)
> The root cause seems to be a specific close scenario of the compare editor,
> so, everyone on this bug please try to remember what you've done when you
> see this again and post it here. Thanks!

This may work if the "specific close scenario" is determined by user actions. If it's determined by internal timing issues, e.g., the best of observations by users isn't worth a lot.

If external observations incl. stack traces and heap dumps witnessing the leak don't help, isn't it time to add more harness into the implementation, to check more assumptions at runtime? Someone is assuming proper cleanup when a compare editor is closed. Some of this cleanup doesn't seem to happen? 

If you add suitable monitoring code I'll be happy to enable that monitoring and upload the logs.

Comment 48 Szymon Ptaszkiewicz 2014-06-04 07:16:39 EDT

*** Bug 436559 has been marked as a duplicate of this bug. ***

Comment 49 Timo Kinnunen 2014-06-10 06:01:29 EDT

Created attachment 244107 [details]
stack trace of a dispose gone wrong

I encountered this for the first time in quite a while. This is the stack trace which appears to set things in motion. It happened one hour after starting the session but I didn't notice something being wrong until about 12 hours later.

I can reproduce the bug on Windows 8 based on that stack trace, with eclipse-SDK-4.4RC3-win32-x86_64:

1) Start with 3 different Java source code files in a project and all editors closed.
2) Select 2 of the files and activate Compare With... -> Each Other.
3) In the opened editor, hover mouse over one JDK class name from either file so that its documentation is displayed in the popup.
4) Double-click the 3rd source code file to open it.
5) Repeat step 3 in this newly opened editor.
6) Without changing to the other tab, close the not active compare view by clicking the X in its tab.
7) An exception shows up in Error Log view.

Comment 50 Stephan Herrmann 2014-06-12 16:51:24 EDT

I can reproduce using steps from comment 49 on Windows 7, but *not* on linux.

Congrats Timo!!

And let's hope, that fixing one root cause will also resolve this for linux ...

Comment 51 Stephan Herrmann 2014-06-14 10:43:55 EDT

See also bug 403253, which produces the same symptoms, but starts with a different exception than the scenario in comment 49. Cf. also comment 0 and comment 35, both of which report JavaReconciler.uninstall in the chain of events leading into the bad state.

Comment 52 Daniel Rolka 2014-08-19 09:05:53 EDT

Released to master as: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ac516641d09a9cb77eca24925debd63f432ae286

Daniel

Comment 53 Stephan Herrmann 2014-08-19 10:10:11 EDT

(In reply to Daniel Rolka from comment #52)
> Released to master 

This sounds really promising! :)

Do you dare predicting, how much of this bug cluster is actually fixed by that patch?

Comment 54 Daniel Rolka 2014-08-20 02:05:47 EDT

(In reply to Stephan Herrmann from comment #53)
> (In reply to Daniel Rolka from comment #52)
> > Released to master 
> 
> This sounds really promising! :)
> 
> Do you dare predicting, how much of this bug cluster is actually fixed by
> that patch?

For sure it fixes the scenario described in the comment 49, that I was able to reproduce. Comparing the stack trace got after following the steps from the comment 49 with other stack traces it seems the cause of the issue is the same - some extra paint event gets propagated during disposing the part

I didn't manage to recreate all scenarios added to the bug, so I think we can try with this patch and see whether it solves all cases or not

Daniel

Comment 55 Stephan Herrmann 2014-08-20 19:12:49 EDT

(In reply to Daniel Rolka from comment #54)
> ... I think we
> can try with this patch and see whether it solves all cases or not

I can't wait to try it :)

You are still planning to get this into SR1? That would be awesome.

Comment 56 Daniel Rolka 2014-08-21 03:56:27 EDT

(In reply to Stephan Herrmann from comment #55)
> (In reply to Daniel Rolka from comment #54)
> > ... I think we
> > can try with this patch and see whether it solves all cases or not
> 
> I can't wait to try it :)
> 
> You are still planning to get this into SR1? That would be awesome.

Yes, I will do it

Daniel

Comment 57 Daniel Rolka 2014-08-25 09:11:38 EDT

The 4.4.1 review link: https://git.eclipse.org/r/#/c/32231/

Daniel

Comment 58 Daniel Rolka 2014-09-03 07:22:37 EDT

Released to the R4_4_maintenance branch as: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=e938dcc5e6ba338d20b13d8a722079f571760496

Daniel

Comment 59 Daniel Rolka 2014-09-04 04:50:13 EDT

Verified in M20140903-0800

Daniel

Comment 60 Szymon Ptaszkiewicz 2014-11-02 13:26:04 EST

According to bug 448968 and its many duplicates this bug still happens on 4.4.1.

Comment 61 Szymon Ptaszkiewicz 2014-12-30 11:09:36 EST

*** Bug 370630 has been marked as a duplicate of this bug. ***

Comment 62 dan carter 2015-04-29 19:05:36 EDT

I had this error all the time on 4.4.1 and on 4.4.2 it seems even worse.  I have to restart eclipse every 20 minutes or so.

!ENTRY org.eclipse.ui 4 0 2015-04-30 10:57:42.164
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.NullPointerException
        at org.eclipse.compare.contentmergeviewer.ContentMergeViewer$ContentMergeViewerLayout.layout(ContentMergeViewer.java:121)
        at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1644)
        at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1650)
        at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1650)
        at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1650)
        at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1650)
        at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1650)
        at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1650)
        at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1650)
        at org.eclipse.swt.widgets.Composite.layout(Composite.java:996)
        at org.eclipse.swt.custom.CTabFolder.runUpdate(CTabFolder.java:3755)
        at org.eclipse.swt.custom.CTabItem.getBounds(CTabItem.java:149)
        at org.eclipse.swt.custom.CTabFolder.onPaint(CTabFolder.java:1993)
        at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.java:289)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4454)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1388)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1412)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1397)
        at org.eclipse.swt.widgets.Control.gtk_expose_event(Control.java:3218)
        at org.eclipse.swt.widgets.Composite.gtk_expose_event(Composite.java:736)
        at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:2091)
        at org.eclipse.swt.widgets.Control.windowProc(Control.java:5534)
        at org.eclipse.swt.widgets.Display.windowProc(Display.java:4668)
        at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
        at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:9106)
        at org.eclipse.swt.widgets.Display.eventProc(Display.java:1253)
        at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method)
        at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2477)
        at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3407)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
        at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
        at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
        at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
        at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
        at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
        at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
        at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
        at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:483)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1465)

Comment 63 Patric Rufflar 2015-09-15 11:51:37 EDT

I'm still seeing this exception in 4.4.2 - should it be reopened?

org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException)
	at org.eclipse.swt.SWT.error(SWT.java:4441)
	at org.eclipse.swt.SWT.error(SWT.java:4356)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:139)
	at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4147)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3764)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032)
	at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148)
	at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1465)
Caused by: java.lang.NullPointerException
	at org.eclipse.compare.contentmergeviewer.ContentMergeViewer$ContentMergeViewerLayout.layout(ContentMergeViewer.java:121)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1290)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1297)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1297)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1297)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1297)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1297)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1297)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1297)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1297)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1297)
	at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1276)
	at org.eclipse.swt.widgets.Composite.layout(Composite.java:665)
	at org.eclipse.swt.custom.CTabFolder.runUpdate(CTabFolder.java:3755)
	at org.eclipse.swt.custom.CTabFolder$10.run(CTabFolder.java:3741)
	at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
	at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136)
	... 23 more

eclipse.buildId=4.4.2.M20150204-1700
java.version=1.8.0_40
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE

Comment 64 Szymon Ptaszkiewicz 2015-09-16 15:54:52 EDT

(In reply to Patric Rufflar from comment #63)
> I'm still seeing this exception in 4.4.2 - should it be reopened?

There is no need to reopen because it did fix part of the problem. Remaining issues are tracked in bug 448968.