Community
Participate
Working Groups
Got myself 6 error log entries like this: I had a type hierarchy on IResource I saved one of my files, and the type hierarchy was recomputing, I hit cancel, the closed the view, then saw these. -- Error Details -- Date: Wed Jul 06 11:52:54 EDT 2011 Message: Problems occurred when invoking code from plug-in: "org.eclipse.jface". Severity: Error Product: Eclipse 1.4.0.20110609-1120 (org.eclipse.epp.package.rcp.product) Plugin: org.eclipse.jface Session Data: eclipse.buildId=I20110613-1736 java.version=1.6.0_26 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US Framework arguments: -product org.eclipse.epp.package.rcp.product Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.rcp.product Exception Stack Trace: java.lang.NullPointerException at java.util.Arrays$ArrayList.<init>(Unknown Source) at java.util.Arrays.asList(Unknown Source) at org.eclipse.jdt.internal.ui.typehierarchy.HierarchyLabelProvider.getImage(HierarchyLabelProvider.java:107) at org.eclipse.jface.viewers.DelegatingStyledCellLabelProvider.getImage(DelegatingStyledCellLabelProvider.java:184) at org.eclipse.jface.viewers.DecoratingStyledCellLabelProvider.getImage(DecoratingStyledCellLabelProvider.java:167) at org.eclipse.jface.viewers.DelegatingStyledCellLabelProvider.update(DelegatingStyledCellLabelProvider.java:118) at org.eclipse.jface.viewers.DecoratingStyledCellLabelProvider.update(DecoratingStyledCellLabelProvider.java:134) at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:152) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:938) at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:106) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:1018) at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:485) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175) at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:2167) at org.eclipse.jface.viewers.StructuredViewer.internalUpdate(StructuredViewer.java:2150) at org.eclipse.jface.viewers.StructuredViewer.update(StructuredViewer.java:2089) at org.eclipse.jface.viewers.ColumnViewer.update(ColumnViewer.java:554) at org.eclipse.jface.viewers.StructuredViewer.update(StructuredViewer.java:2033) at org.eclipse.jface.viewers.StructuredViewer.handleLabelProviderChanged(StructuredViewer.java:1191) at org.eclipse.jdt.internal.ui.viewsupport.ProblemTreeViewer.handleLabelProviderChanged(ProblemTreeViewer.java:223) at org.eclipse.jface.viewers.ContentViewer$1.labelProviderChanged(ContentViewer.java:97) at org.eclipse.jface.viewers.BaseLabelProvider$1.run(BaseLabelProvider.java:74) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175) at org.eclipse.jface.viewers.BaseLabelProvider.fireLabelProviderChanged(BaseLabelProvider.java:72) at org.eclipse.jface.viewers.DecoratingStyledCellLabelProvider$1.labelProviderChanged(DecoratingStyledCellLabelProvider.java:77) at org.eclipse.ui.internal.decorators.DecoratorManager$1.run(DecoratorManager.java:430) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.decorators.DecoratorManager.fireListener(DecoratorManager.java:428) at org.eclipse.ui.internal.decorators.DecorationScheduler$3.runInUIThread(DecorationScheduler.java:529) at org.eclipse.ui.progress.UIJob$1.run(UIJob.java:95) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4140) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3757) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) 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:344) 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:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
Probably not for 3.7.1.
SR1 surely. It looks like a simple guard check. I'm seeing this too. But it's much more prolific. Every time I try to to run a Junit test, I get a load of these errors, and I think a load of wasted CPU time too. I'm not sure quite what triggered it, but I do have a sick Type Hierarchy view (displaying the initial select a type instruction). I may be seeing a greater problem because I'm getting an NPE from each of my 8 hierarchies. I've seen it before but blamed it on something else then.
I actually get 70-odd error log entries per JUnit run and a couple per JDT editor incremental build. Very irritating having to close a pop-up every couple of editor actions. Closing the Type Hierarchy in _all_ perspectives stops the errors.
Edward, it would be good to have exact steps that allow us to reproduce what you see.
I cannot recall all the debugging actions I used. I was certainly using the Type Hierarchy view and may have got bored while some hierarchy such as Iterable was taking too long and so changed views and caused concurrent activity. However my observations of the inconvenience would suggest that a) some variable clearly can be null in an unexpected way and that can be guarded in the code. b) type hierarchies are being recomputed too aggressively; minor JDT edits should not provoke major activity; in particular, prior to a Save, should the hierarchy update at all. b) may be related to an undiagnosed problem whereby the builder appears to do repeated full builds in conjunction with some of Acceleo, Xtext, Papyrus, Modisco. Something is certainly triggering something else to do much much more than is desirable.
I didn't see an obvious code path where fHierarchy.getInputElement() would be null. However, in 3.6, the line in HierarchyLabelProvider.getImage(..) looked like this, and thus contained an implicit null check: if (element.equals(fHierarchy.getInputElement())) { We should restore that for 3.7.1. Raksha, please open a call hierarchy on TypeHierarchyLifeCycle#fInputElements and then prepare a patch that fixes all places where null checks and equals(..) tests have not been converted properly when we changed IJavaElement fInputElement; to IJavaElement[] fInputElements; E.g. in TypeHierarchyLifeCycle#doHierarchyRefresh(..), we use "elements.equals(fInputElements)" in 3.7, which doesn't make sense for arrays.
Created attachment 201216 [details] Patch (In reply to comment #6) Added null checks after calls to fHierarchy.getInputElement() > "elements.equals(fInputElements)" in 3.7, which doesn't make sense for arrays. Yep, replaced equals with Array.equals(..). Markus, could you pls review? TIA.
Patch looks good.
It looks like this got committed to HEAD.
(In reply to comment #9) > It looks like this got committed to HEAD. Yes. Also committed to R3_7_maintenance branch.
Released into R3_7_maintenance. Available in M20110817-0800.
Verified in M20110824-0800 by code inspection and by trying various scenarios with multiple inputs and cancelling.
