Community
Participate
Working Groups
Version: 4.2.1 Build id: M20120914-1800 I have been seeing an NPE in WorkbenchPage#busyShowView in my RCP application. I can reproduce this in Eclipse as follows: With a clean workspace: 1. Open Eclipse 2. Switch to the Debug perspective 3. Click Window -> Show View -> Other 4. Select the following views: Error Log, Progress, Help, and Call Hierarchy. Click OK. 5. Note that the Call Hierachy view has not opened 6. Note that an NPE has been logged - stack trace below. The code in question has a null guard for the compatibilityView variable, but calls a method on it outside of the null guard, which does not seem right: > if (compatibilityView != null) { > IWorkbenchPartReference ref = compatibilityView.getReference(); > > legacyWindow.firePerspectiveChanged(this, getPerspective(), ref, CHANGE_VIEW_SHOW); > legacyWindow.firePerspectiveChanged(this, getPerspective(), CHANGE_VIEW_SHOW); > } > return compatibilityView.getView(); Note that bug 377343 exhibits the same stack trace. I don't think this is the same as bug 355456 (reported against v3.6.1) as the code is completely different now. Stack trace: org.eclipse.e4.core.di.InjectionException: java.lang.NullPointerException at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:63) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:229) at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:210) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:131) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:171) at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:500) at org.eclipse.ui.internal.ShowViewMenu$3.run(ShowViewMenu.java:141) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1276) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3554) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3179) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1029) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:923) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:86) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:588) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:543) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) 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:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) 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:601) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) Caused by: java.lang.NullPointerException at org.eclipse.ui.internal.WorkbenchPage.busyShowView(WorkbenchPage.java:1179) at org.eclipse.ui.internal.WorkbenchPage$9.run(WorkbenchPage.java:3774) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.WorkbenchPage.showView(WorkbenchPage.java:3771) at org.eclipse.ui.internal.WorkbenchPage.showView(WorkbenchPage.java:3747) at org.eclipse.ui.handlers.ShowViewHandler.openView(ShowViewHandler.java:126) at org.eclipse.ui.handlers.ShowViewHandler.openOther(ShowViewHandler.java:99) at org.eclipse.ui.handlers.ShowViewHandler.execute(ShowViewHandler.java:67) at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:290) at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:76) 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:601) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56) ... 35 more
I can reproduce this from an empty workspace. Eric, do you think this might be because there's a placeholder for call hierarchy in the java perspective that hasn't been instantiated? PW
On further investigation I can reproduce this with views other than Call Hierarchy. Of the Java views, you can also see this with Declaration, Javadoc and JUnit but not Package Explorer or Type Hierarchy. I have not tried views from other categories.
I've just tried this on M20130109-1200 and so far don't see any issues regardless of the view / perspective I use. Is it possible that there's some missing required bundles in your configuration ? What I'm thinking is that it's possible to include the bundle *defining* the view (so it appears in the dialog) without having all the bundles it needs included (so it crashes on creation). You're correct though in that if 'compatibilityView' code at the end of the method should be refactored, likely to throw an exception (PartInitException?) if true and just proceed otherwise...
(In reply to comment #3) > I've just tried this on M20130109-1200 and so far don't see any issues > regardless of the view / perspective I use. > > Is it possible that there's some missing required bundles in your > configuration ? What I'm thinking is that it's possible to include the > bundle *defining* the view (so it appears in the dialog) without having all > the bundles it needs included (so it crashes on creation). I was able to reproduce this with the SDK and starting in a completely empty workspace, following the steps from comment #0 Eric, could you try again? If you can't reproduce this maybe it's a linux only problem PW
we have this problem in a custom RCP application since switching from 3.8 to 4.3. you have my vote :)
Got it...I suspect I didn't select *all* the views... I'll put this one next on my hit list.
I just tried the scenario as given in the first comment again with 4.4.0.I20131001-0800 and don't seem to be able to reproduce anymore, can anybody else verify that it's fixed ?
I am able to reproduce on: Version: 4.4.0 Build id: I20131001-0800 I will try to fix this.
The issue seems to be that WorkbenchPage.getViewReference returns null for the part corresponding to the Call Hierarchy view.
Note to self: PartServiceImpl.isInContainer returns false for Call Hierarchy, preventing the corresponding ViewReference to be added to viewReferences. Evenatually, this causes WorkbenchPage.getViewReference to return null.
General scenario to reproduce the bug: 1. Open Help view. 2. Open a new perspective. 3. Focus the Help view. 4. Open one of views that by default opens in a container of the secondaryDataStack type, e.g. Call hierarchy. The problem is caused by the PartServiceImpl.addPart(MPart, MPart) method. When the Help view is focused, the PartServiceImpl.getContainer() method returns the MWindow instead of active perspective (because the Help view is inside the right "sticky folder", which in turn is outside the perspective stack). Then EModelService.findElements(*) returns all suitable part containers from all perspectives. Eventually, the newly opened view is added to the first of the containers, which is not always inside the active perspective. My fix proposition is to accept only part containers from the active perspective. Review URL: https://git.eclipse.org/r/#/c/18754/ During testing I have not found any side effects of the fix.
Committed (on Wojciech's behalf), thanks ! http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=3b3894f712dd09df69050b01fa492960a9705a96
Verified in I20131209-2000.
Backported to 4.2.2+ with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=8955eeca53af81244ce0d8315c5b09108bbed7fb Backported to 4.3.2+ with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b976f2bf77a78ec678e416375fd1cb1444d237cf
