Community
Participate
Working Groups
i get this null pointer suddenly with Eclipse 4.15, 4.14 worked fine: java.lang.NullPointerException at org.eclipse.help.ui.internal.views.ReusableHelpPart.flipPages(ReusableHelpPart.java:1074) at org.eclipse.help.ui.internal.views.ReusableHelpPart.showPage(ReusableHelpPart.java:1039) at org.eclipse.help.ui.internal.views.ReusableHelpPart.openInternalBrowser(ReusableHelpPart.java:1327) at org.eclipse.help.ui.internal.views.ReusableHelpPart.showURL(ReusableHelpPart.java:1306) at org.eclipse.help.ui.internal.views.ReusableHelpPart.lambda$2(ReusableHelpPart.java:1283) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:72) at org.eclipse.help.ui.internal.views.ReusableHelpPart.showURL(ReusableHelpPart.java:1283) at org.eclipse.help.ui.internal.views.HelpView.showHelp(HelpView.java:380) at org.eclipse.help.ui.internal.DefaultHelpUI.displayContext(DefaultHelpUI.java:354) at org.eclipse.help.ui.internal.DefaultHelpUI.displayContext(DefaultHelpUI.java:307) at org.eclipse.ui.internal.help.WorkbenchHelpSystem.displayContext(WorkbenchHelpSystem.java:750) at org.eclipse.ui.internal.help.WorkbenchHelpSystem$WorkbenchHelpListener.helpRequested(WorkbenchHelpSystem.java:133) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:157) that is because of this fully stack: See the 2 inline comments, somehow it destroyes its own HelpView and ReusableHelpPart which is just busy showing something: Thread [main] (Suspended (breakpoint at line 1158 in ReusableHelpPart)) ReusableHelpPart.dispose() line: 1158 <<<<<<<<<<<<<<<<<<< See below in a setVisible call now the ReusableHelpPart is destroyed when it is busy showing something HelpView.dispose() line: 100 CompatibilityView(CompatibilityPart).invalidate() line: 260 CompatibilityView(CompatibilityPart).destroy() line: 417 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 MethodRequestor.execute() line: 58 InjectorImpl.processAnnotated(Class<Annotation>, Object, Class<?>, PrimaryObjectSupplier, PrimaryObjectSupplier, ArrayList<Class<?>>) line: 1002 InjectorImpl.processAnnotated(Class<Annotation>, Object, Class<?>, PrimaryObjectSupplier, PrimaryObjectSupplier, ArrayList<Class<?>>) line: 967 InjectorImpl.uninject(Object, PrimaryObjectSupplier) line: 200 FieldRequestor(Requestor<L>).uninject(Object, PrimaryObjectSupplier) line: 176 ContextObjectSupplier$ContextInjectionListener.update(IEclipseContext, int, Object[]) line: 89 TrackableComputationExt.update(ContextChangeEvent) line: 105 EclipseContext.removeListenersTo(Object) line: 491 ContextInjectionFactory.uninject(Object, IEclipseContext) line: 184 PartRenderingEngine.safeRemoveGui(MUIElement) line: 954 PartRenderingEngine.access$1(PartRenderingEngine, MUIElement) line: 873 PartRenderingEngine$4.run() line: 868 SafeRunner.run(ISafeRunnable) line: 45 PartRenderingEngine.removeGui(MUIElement) line: 852 ElementReferenceRenderer.disposeWidget(MUIElement) line: 115 PartRenderingEngine.safeRemoveGui(MUIElement) line: 945 PartRenderingEngine.access$1(PartRenderingEngine, MUIElement) line: 873 PartRenderingEngine$4.run() line: 868 SafeRunner.run(ISafeRunnable) line: 45 PartRenderingEngine.removeGui(MUIElement) line: 852 PartRenderingEngine.subscribeTopicToBeRendered(Event) line: 187 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 MethodRequestor.execute() line: 58 EventObjectSupplier$DIEventHandler.handleEvent(Event) line: 92 EventHandlerWrapper.handleEvent(Event, Permission) line: 205 EventHandlerTracker.dispatchEvent(EventHandlerWrapper, Permission, int, Event) line: 203 EventHandlerTracker.dispatchEvent(Object, Object, int, Object) line: 1 EventManager.dispatchEvent(Set<Entry<K,V>>, EventDispatcher<K,V,E>, int, E) line: 234 ListenerQueue<K,V,E>.dispatchEventSynchronous(int, E) line: 151 EventAdminImpl.dispatchEvent(Event, boolean) line: 132 EventAdminImpl.sendEvent(Event) line: 75 EventComponent.sendEvent(Event) line: 44 EventBroker.send(String, Object) line: 55 UIEventPublisher.notifyChanged(Notification) line: 63 PlaceholderImpl(BasicNotifierImpl).eNotify(Notification) line: 424 PlaceholderImpl(UIElementImpl).setToBeRendered(boolean) line: 314 ModelServiceImpl.hideLocalPlaceholders(MWindow, MPerspective) line: 1140 PartRenderingEngine.subscribeChildrenHandler(Event) line: 333 GeneratedMethodAccessor12.invoke(Object, Object[]) line: not available DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 MethodRequestor.execute() line: 58 EventObjectSupplier$DIEventHandler.handleEvent(Event) line: 92 EventHandlerWrapper.handleEvent(Event, Permission) line: 205 EventHandlerTracker.dispatchEvent(EventHandlerWrapper, Permission, int, Event) line: 203 EventHandlerTracker.dispatchEvent(Object, Object, int, Object) line: 1 EventManager.dispatchEvent(Set<Entry<K,V>>, EventDispatcher<K,V,E>, int, E) line: 234 ListenerQueue<K,V,E>.dispatchEventSynchronous(int, E) line: 151 EventAdminImpl.dispatchEvent(Event, boolean) line: 132 EventAdminImpl.sendEvent(Event) line: 75 EventComponent.sendEvent(Event) line: 44 EventBroker.send(String, Object) line: 55 UIEventPublisher.notifyChanged(Notification) line: 63 ToolBarImpl(BasicNotifierImpl).eNotify(Notification) line: 424 ToolBarImpl$1(EcoreEList<E>).dispatchNotification(Notification) line: 249 ToolBarImpl$1(NotifyingListImpl<E>).addUnique(int, E) line: 356 ToolBarImpl$1(AbstractEList<E>).add(int, E) line: 340 ECollections.setEList(EList<T>, List<? extends T>) line: 228 ToolBarManagerRenderer.reconcileManagerToModel(IToolBarManager, MToolBar) line: 984 ActionBars.updateActionBars() line: 97 SubActionBars.updateActionBars() line: 602 ReusableHelpPart$HelpPartPage.setVisible(boolean) line: 534 <<<<<<<<<<<<<<<<<< This will cause a destroy of it self, the ReusableHelpPart ReusableHelpPart.flipPages(ReusableHelpPart$HelpPartPage, ReusableHelpPart$HelpPartPage) line: 1072 ReusableHelpPart.showPage(String) line: 1039 ReusableHelpPart.openInternalBrowser(String) line: 1327 ReusableHelpPart.showURL(String, boolean) line: 1306 ReusableHelpPart.lambda$2(String) line: 1283 1761324386.run() line: not available BusyIndicator.showWhile(Display, Runnable) line: 72 ReusableHelpPart.showURL(String) line: 1283 HelpView.showHelp(String) line: 380 DefaultHelpUI.displayContext(IContext, int, int, boolean) line: 354 DefaultHelpUI.displayContext(IContext, int, int) line: 307 WorkbenchHelpSystem.displayContext(IContext, int, int) line: 750 WorkbenchHelpSystem$WorkbenchHelpListener.helpRequested(HelpEvent) line: 133 i tracked it down because of the contributions the toolbarmanager of the helpview has, When it is created: Thread [main] (Suspended) ToolBarManagerRenderer.reconcileManagerToModel(IToolBarManager, MToolBar) line: 971 CompatibilityView.createPartControl(IWorkbenchPart, Composite) line: 178 CompatibilityView(CompatibilityPart).create() line: 361 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 MethodRequestor.execute() line: 58 InjectorImpl.processAnnotated(Class<Annotation>, Object, Class<?>, PrimaryObjectSupplier, PrimaryObjectSupplier, ArrayList<Class<?>>) line: 1002 InjectorImpl.processAnnotated(Class<Annotation>, Object, Class<?>, PrimaryObjectSupplier, PrimaryObjectSupplier, ArrayList<Class<?>>) line: 967 InjectorImpl.internalInject(Object, PrimaryObjectSupplier, PrimaryObjectSupplier) line: 139 InjectorImpl.internalMake(Class<?>, PrimaryObjectSupplier, PrimaryObjectSupplier) line: 408 InjectorImpl.make(Class<T>, PrimaryObjectSupplier) line: 331 ContextInjectionFactory.make(Class<T>, IEclipseContext) line: 202 ReflectionContributionFactory.createFromBundle(Bundle, IEclipseContext, IEclipseContext, URI) line: 91 ReflectionContributionFactory.doCreate(String, IEclipseContext, IEclipseContext) line: 60 ReflectionContributionFactory.create(String, IEclipseContext) line: 42 ContributedPartRenderer.createWidget(MUIElement, Object) line: 132 PartRenderingEngine.createWidget(MUIElement, Object) line: 1002 PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 662 PartRenderingEngine$1.run() line: 547 SafeRunner.run(ISafeRunnable) line: 45 PartRenderingEngine.createGui(MUIElement, Object, IEclipseContext) line: 531 ElementReferenceRenderer.createWidget(MUIElement, Object) line: 73 PartRenderingEngine.createWidget(MUIElement, Object) line: 1002 PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 662 PartRenderingEngine.safeCreateGui(MUIElement) line: 768 PartRenderingEngine.access$0(PartRenderingEngine, MUIElement) line: 739 PartRenderingEngine$2.run() line: 733 SafeRunner.run(ISafeRunnable) line: 45 PartRenderingEngine.createGui(MUIElement) line: 717 PartRenderingEngine.subscribeTopicToBeRendered(Event) line: 161 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 MethodRequestor.execute() line: 58 EventObjectSupplier$DIEventHandler.handleEvent(Event) line: 92 EventHandlerWrapper.handleEvent(Event, Permission) line: 205 EventHandlerTracker.dispatchEvent(EventHandlerWrapper, Permission, int, Event) line: 203 EventHandlerTracker.dispatchEvent(Object, Object, int, Object) line: 1 EventManager.dispatchEvent(Set<Entry<K,V>>, EventDispatcher<K,V,E>, int, E) line: 234 ListenerQueue<K,V,E>.dispatchEventSynchronous(int, E) line: 151 EventAdminImpl.dispatchEvent(Event, boolean) line: 132 EventAdminImpl.sendEvent(Event) line: 75 EventComponent.sendEvent(Event) line: 44 EventBroker.send(String, Object) line: 55 UIEventPublisher.notifyChanged(Notification) line: 63 PlaceholderImpl(BasicNotifierImpl).eNotify(Notification) line: 424 PlaceholderImpl(UIElementImpl).setToBeRendered(boolean) line: 314 ModelServiceImpl.showElementInWindow(MWindow, MUIElement) line: 656 ModelServiceImpl.bringToTop(MUIElement) line: 625 PartServiceImpl.delegateBringToTop(MPart) line: 790 PartServiceImpl.activate(MPart, boolean, boolean) line: 761 PartServiceImpl.activate(MPart, boolean) line: 683 PartServiceImpl.activate(MPart) line: 678 PartServiceImpl.showPart(MPart, EPartService$PartState) line: 1257 it starts with 2 contributions back=org.eclipse.e4.ui.model.application.ui.menu.impl.DirectToolItemImpl@635b3ec7 (tags: [Opaque], contributorURI: null) (widget: null, renderer: org.eclipse.e4.ui.workbench.renderers.swt.ToolBarManagerRenderer@9a07409, toBeRendered: true, onTop: false, visible: true, containerData: null, accessibilityPhrase: null) (label: null, iconURI: null, tooltip: null, enabled: true, selected: false, type: Push) (contributionURI: null, object: null) next=org.eclipse.e4.ui.model.application.ui.menu.impl.DirectToolItemImpl@15aa3084 (tags: [Opaque], contributorURI: null) (widget: null, renderer: org.eclipse.e4.ui.workbench.renderers.swt.ToolBarManagerRenderer@9a07409, toBeRendered: true, onTop: false, visible: true, containerData: null, accessibilityPhrase: null) (label: null, iconURI: null, tooltip: null, enabled: true, selected: false, type: Push) (contributionURI: null, object: null) these are here just before the above stack. Thread [main] (Suspended (breakpoint at line 84 in ContributionManager)) ToolBarManager(ContributionManager).add(IContributionItem) line: 84 ToolBarManager(ContributionManager).add(IAction) line: 77 ReusableHelpPart.makeActions() line: 889 ReusableHelpPart.init(IActionBars, IToolBarManager, IStatusLineManager, IMenuManager, IMemento) line: 850 HelpView.init(IViewSite, IMemento) line: 118 ViewReference.initialize(IWorkbenchPart) line: 128 but after the creation we get this: and that adds the 6 other contributions that when it works in an older version where there from the get go. Thread [main] (Suspended (breakpoint at line 354 in ContributionManager)) ToolBarManager(ContributionManager).insertBefore(String, IContributionItem) line: 354 SubToolBarManager(SubContributionManager).insertBefore(String, IContributionItem) line: 151 SubToolBarManager(SubContributionManager).insertBefore(String, IAction) line: 144 BrowserPart.contributeToToolBar(IToolBarManager) line: 275 BrowserPart.<init>(Composite, FormToolkit, IToolBarManager, IMenuManager) line: 191 ReusableHelpPart.createPart(String, IToolBarManager, IMenuManager) line: 1227 ReusableHelpPart.access$4(ReusableHelpPart, String, IToolBarManager, IMenuManager) line: 1208 ReusableHelpPart$HelpPartPage.createRecPart(ReusableHelpPart$PartRec) line: 556 ReusableHelpPart$HelpPartPage.canOpen() line: 447 ReusableHelpPart.flipPages(ReusableHelpPart$HelpPartPage, ReusableHelpPart$HelpPartPage) line: 1068 ReusableHelpPart.showPage(String) line: 1039 ReusableHelpPart.openInternalBrowser(String) line: 1327 ReusableHelpPart.showURL(String, boolean) line: 1306 ReusableHelpPart.lambda$2(String) line: 1283 2039642748.run() line: not available BusyIndicator.showWhile(Display, Runnable) line: 72 ReusableHelpPart.showURL(String) line: 1283 HelpView.showHelp(String) line: 380 DefaultHelpUI.displayContext(IContext, int, int, boolean) line: 354 DefaultHelpUI.displayContext(IContext, int, int) line: 307 WorkbenchHelpSystem.displayContext(IContext, int, int) line: 750 WorkbenchHelpSystem$WorkbenchHelpListener.helpRequested(HelpEvent) line: 133 and because of that when this is called again: (throug flipPages) ReusableHelpPart$HelpPartPage.setVisible(boolean) we get into a state taht we call ToolBarImpl$1(AbstractEList<E>).add(int, E) line: 340 ECollections.setEList(EList<T>, List<? extends T>) line: 228 because the number of contributions is suddenly increased from 2 to 8 from the moment it was first created and now it wants to show a new page.. and because of that fire, Eclipse suddenly thinks (no idea why that is ) that i needs to remove the part completely... But when it works (so older eclipse version, 4,14) it is the same it first has 2 and then has 8, and it also gets into that ToolBarImpl$1(AbstractEList<E>).add(int, E) line: 340 But then its very hard to track why in a newer version it suddenly calls PartRenderingEngine.safeRemoveGui(MUIElement) line: 954 and in the older version it never hits that code. Any idea where i can really look into to see what the difference really is?
Johan, can you please attach a small reproducible example (e.g. plugin that contributes whatever you contribute to the help) with steps to reproduce? Also in the title you says that "broken in 4.16 (4.15 it did work fine)", but in the comment 0 you say "i get this null pointer suddenly with Eclipse 4.15, 4.14 worked fine". So which exact Eclipse version shows the problem? 4.15 or 4.16?
i right we skipped one release thats why i was confused 4.14 (our 2020.03 product) is working fine 4.15 and also 4.16 (just tested) have the same problem i looked at it a bit more to try to understand it Placed 3 breakpoints: HelpView.init() (113) ToolBarManagerRenderer.reconcileManagerToModel() (970) PartRenderingEngine.subscribeTopicToBeRendered() (139) And at the moment i press F1 i look what hits first for 4.14 HelpView.init 2 times TBMR (with actions size of 2, coming from CompartibiltyView.create() and PRE.safeCreateGUI) PRE with changedElement.isToBeRendered() == true (so it will show the part) TBMR with size 8 is called (twice) no more PRE called But in a 4.15: HelpView.init 2 times TBMR (with actions size of 2, coming from CompartibiltyView.create() and PRE.safeCreateGUI) TBMR with size 8 is called once that results in: PRE with changedElement.isToBeRendered() == false so the big change here is that there doesn't seem to be an event that PRE is called to actual do stuff for the visible = true part in subscribeTopicToBeRendered that is skipped and then its triggered but then right away with it thinking it should remove/hide it. i can try to make something simple but that will not be that easy i think for a quick test: http://download.servoy.com/beta/latest/servoy_windows.3580.zip unzip, start in developer\servoy.exe ignore.skip the 2 dialogs and just press F1 (when the focus is on the Solution Explorer View)
My first guess is that this bug is caused by two issues: 1. The root cause of Bug 562645, that is, action contributions are not handled correctly. Are you using action contributions in the toolbar? 2. As a result of 1, new items are added to the toolbar. This should not result in closing a part. PartRenderingEngine#subscribeChildrenHandler calls modelService.hideLocalPlaceholders after adding a toolbar item, that seems very strange.
We dont use anything in that area we just have context enabled help enabled. So if you press F1 then it will just display the current view help So there is almost no code that is ours, its fully eclipse i think the only real code that is hit is our: public Object getAdapter(Class type) { if (type.equals(IContextProvider.class)) { return new ViewPartHelpContextProvider("com.servoy.eclipse.ui.solution_explorer"); } return super.getAdapter(type); } of the ViewPart that "com.servoy.eclipse.ui.solution_explorer" is the contexts.xml help file: <context id="solution_explorer" title="Solution Explorer"> <topic href="https://servoy.github.io/servoy_documentation/201903/solution_explorer.html" label="Solution Explorer"/> </context> so we only have single topic help thing that makes the Help Plugin of Eclipse just show that right away as is (so not first a index page pointing to that topic) so it has to show right away just the browser view I just can't get that to work in a very simple example, first of all F1 on a view is not working for me (i think for that i need to really initialize better the help system, so it has a File provider) But besides that even if i toggle it through the menu, then click on the view, then my simple example works, but doing the same thing in the app itself fails with the null pointer.
hideLocalPlaceholders will hide (toBeRendered false) on a placeholder in a Perspective is the referenced part is also 'globally visible', that is outside the perspective or in the shared area. Apparently that is the case for your application. The hiding of a part can be reproduced by making two placeholders, and adding a toolbar item to the part. This behavior is a regression from Bug 339573 that hideLocalPlaceholders is not only called on placeholders but on any element. This bug should be used to track that regression. The illegal addition of toolbar elements will be tracked in Bug 562645.
New Gerrit change created: https://git.eclipse.org/r/164935
that patch works yes as far as i did test now that "added" is a few times hit now but with "org.eclipse.e4.ui.model.application.ui.menu.impl.DirectToolItemImpl" so it doesn't go into that if anymore. I will try to apply that patch in our product for the coming 2 versions i guess
(In reply to Johan Compagner from comment #7) > that patch works yes as far as i did test now > that "added" is a few times hit now but with > "org.eclipse.e4.ui.model.application.ui.menu.impl.DirectToolItemImpl" > > so it doesn't go into that if anymore. > > I will try to apply that patch in our product for the coming 2 versions i > guess I would expect that if you include the patch for Bug 562645, is not 'added' is never hit either. Probably you want that patch too, to prevent more issues. (And if you are providing your custom backports of issues to previous releases, you might be interested to do that on the maintenance branches, such that more could benefit from that)
is: Bug 562645 fixing the same thing then? Does eclipse have maintenance builds really on older versions? For now i just patch it right into our product like this: https://github.com/Servoy/servoy-eclipse/blob/master/org.eclipse.jface/pom.xml (thats a patched jface plugin that we need, but is not really a bug in eclipse, just an extra feature we need to have to be able to override all images that we want in the product) But making a gerrit change for this on the [R4_15-branch] branch is very easy to do if that would be applied to that (and then really build?) also.
(In reply to Johan Compagner from comment #9) > is: Bug 562645 fixing the same thing then? Not the same thing, but that bug triggers this bug. I expect that if that bug is fixed, your issue will go away too. > Does eclipse have maintenance builds really on older versions? There are maintenance branches, but no builds see Bug 561613. > For now i just patch it right into our product like this: > > https://github.com/Servoy/servoy-eclipse/blob/master/org.eclipse.jface/pom. > xml > > (thats a patched jface plugin that we need, but is not really a bug in > eclipse, just an extra feature we need to have to be able to override all > images that we want in the product) > > But making a gerrit change for this on the [R4_15-branch] branch is very > easy to do if that would be applied to that (and then really build?) also. That functionality might be interesting to others too, see for instance Bug 562174. But I don't think that new API will be added on maintenance branches.
> > That functionality might be interesting to others too, see for instance Bug > 562174. But I don't think that new API will be added on maintenance branches. i just pushed for our product 2 commits: https://github.com/Servoy/servoy-eclipse/commit/d2f8a60df3c1fbedde329cd3f6439987350db747 this is a plain copy of the whole plugin that i want to patch (so as is from the branch i target) https://github.com/Servoy/servoy-eclipse/commit/d04404b4694b3cfdd731b4c8e13bffdb02784ebe this commit has the actual patch and i fix the version to the one that is really in my eclipse release. added a pom.xml that makes this plugin belong to my parent pom (parent pom also has this one now as a module) and i with the maven-dependency-plugin copy goal i just push my patched plugin over the osgi locations of my local maven repo. So when i really build the product that plugin is taken instead of the one from eclipse itself. This works for use already for quite a while on various patches that i need (for a while) Its a bit hacky, but else i would have to checkout and build (and patch) really an eclipse git repo, and make sure that that one is then used.. (also on jenkins and other places where people can make build from our product, every developer should be able to do this locally) i am not 100% sure if that copy is really needed and if tycho would not just take the local one first.. But i really want to be sure that one is used
(In reply to Johan Compagner from comment #11) > Its a bit hacky, but else i would have to checkout and build (and patch) > really an eclipse git repo, and make sure that that one is then used.. > (also on jenkins and other places where people can make build from our > product, every developer should be able to do this locally) Just choose what works best for you. My final comment on this: You might be interested in using feature patches [1]. Though tycho support is a bit tricky here, see Bug 378794. https://www.vogella.com/tutorials/EclipsePatching/article.html
Gerrit change https://git.eclipse.org/r/164935 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=638525c5bf7100422d7c47ab6ed4ea2f45c81f84
