Community
Participate
Working Groups
I have a very simple extension point that provides a factory. On 4.3 Kepler, exactly the same plug-ins seem to be fine. On 4.4, after the factory proxy calls createExecutableExtension() and returns to Eclipse, I notice a StackOverflow: !ENTRY org.eclipse.e4.ui.workbench.renderers.swt 4 2 2014-07-21 19:08:01.022 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.e4.ui.workbench.renderers.swt". !STACK 0 org.eclipse.e4.core.di.InjectionException: java.lang.StackOverflowError at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:62) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:247) at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:229) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132) at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.setEnabled(HandlerServiceHandler.java:77) at org.eclipse.core.commands.Command.setEnabled(Command.java:886) Apart from the delay to write the almost 600K log entry, functionality seems not affected.
Created attachment 245241 [details] full stack overflow log
What causes your plugin to read your extension point? PW
Further test apparently ruled out the extension point, the plug-in where the extension point is instantiated gives this exception even if I load and start it normally, using a button in the toolbar. I tested on Windows 7 and the behaviour is consistent, exactly the same plug-ins work on 4.3 and crash on 4.4.
On Windows the message was completely different: !ENTRY org.eclipse.e4.ui.workbench 4 0 2014-07-22 00:17:18.584 !MESSAGE Internal error during tool item enablement updating, this is only logged once per tool item. !STACK 0 org.eclipse.e4.core.di.InjectionException: java.lang.StackOverflowError at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:62) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:247)
I got the 'Internal error during tool item enablement updating, this is only logged once per tool item.' message on OS X too. The plug-in that triggers the exception is very simple, just an extension point: <plugin> <extension point="ilg.gnuarmeclipse.packs.core.data"> <factory class="ilg.gnuarmeclipse.packs.data.DataManagerFactory" name="My Factory"> </factory> </extension> </plugin> so it has not enablements at all. This extension point is executed when another plug-in, not having a hard wired dependency on it, requests some data to be displayed in one of the project properties pages. The plug-in is also loaded when another plug-in, that has a hard wired dependency, directly instantiates some classes. The plugin.xml being so simple, I thought it might be something strange in the java classes, but, as far as I can tell, there are no annotations (except @Override) or other fancy things there, just plain java, occasionally with some embedded classes.
If you want to reproduce this bug, please install the plug-ins from: http://sourceforge.net/projects/gnuarmeclipse/files/Current%20Releases/2.x/ilg.gnuarmeclipse.repository-2.3.2-201407190854.zip/download The plug-ins requires CDT. The bug occurs when the ilg.managedbuild.packs is activated, in fact a few moments later, probably during some background jobs, like enablement evaluation. To reach this point, after installing my plug-ins, you need to switch to the Packs perspective, using the custom toolbar button with two brown packages. Further tests revealed that the problem is not at all related to the extension point, but to the content of the plug-in. I tried to simplify the packs plug-in, I moved big parts of it to another plug-in, I also commented out the entire plug-in.xml, and the behaviour is consistent, it always occurs after the classes are loaded and executed (mainly showing the new perspective). Unfortunately I do not have the eclipse sources in my development environment, and have no experience with the enablement plug-ins, so I cannot go further.
I have a repro for the exact same StackOverflowError (judging from the stack trace). In my case I just have a sub-class of DebugCommandHandler registered as a command in plugin.xml. Stack overflow occurs when I launch Eclipse in Java perspective and then switch to Debug perspective. Launching Eclipse in Debug perspective seems to work fine. The stack trace doesn't show a single line of my own code. FWIW: this is from the bottom of the stack, how we enter that recursion: ToolItemUpdater.updateContributionItems(Selector) line: 39 ToolBarManagerRenderer.updateRequest(Event) line: 295 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: 483 MethodRequestor.execute() line: 55 UIEventObjectSupplier$UIEventHandler$1.run() line: 56 UISynchronizer(Synchronizer).syncExec(Runnable) line: 187 UISynchronizer.syncExec(Runnable) line: 156 Display.syncExec(Runnable) line: 4622 E4Application$1.syncExec(Runnable) line: 218 UIEventObjectSupplier$UIEventHandler.handleEvent(Event) line: 53 EventHandlerWrapper.handleEvent(Event, Permission) line: 197 EventHandlerTracker.dispatchEvent(EventHandlerWrapper, Permission, int, Event) line: 197 EventHandlerTracker.dispatchEvent(Object, Object, int, Object) line: 1 EventManager.dispatchEvent(Set<Entry<K,V>>, EventDispatcher<K,V,E>, int, E) line: 230 ListenerQueue<K,V,E>.dispatchEventSynchronous(int, E) line: 148 EventAdminImpl.dispatchEvent(Event, boolean) line: 135 EventAdminImpl.sendEvent(Event) line: 78 EventComponent.sendEvent(Event) line: 39 EventBroker.send(String, Object) line: 81 WorkbenchWindow.updateActionBars() line: 2301 WWinActionBars.updateActionBars() line: 122 ActionBars(SubActionBars).updateActionBars() line: 621 ActionBars.updateActionBars() line: 130 LaunchView(PageBookView).showPageRec(PageBookView$PageRec) line: 1061
this is just one of the very annoying Luna behaviours, which prevent me from recommending Luna :-( any chances to fix it?
Created attachment 249181 [details] Plugin to reproduce overflow I can reproduce that bug easily by creating a new button that points to an existing platform debug commandId. I'm running 4.5M3. We believe this can cause serious problems, as one bad contribution can cause many other buttons to no longer work in some cases. Attached is a very small plugin that just adds the button. To reproduce: 1- import attached plugin 2- launch a test eclipse 3- a new button should be seen in the main toolbar. It looks like a 'reverse resume' 4- press the button => stack overflow Let me know if you need more info.
This affects all platforms. I've also bumped it to major as it can cause many buttons to never be enabled until a restart. For instance, we've had many reports of all debug buttons remaining disabled. If my understanding of the problem is wrong, feel free to reduce the priority.
any progress on this? as shown by the logs, we have a clear case of infinite recursion here, the following sequence repeats all over again: at org.eclipse.core.commands.Command.setEnabled(Command.java:886) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.canExecute(HandlerServiceImpl.java:179) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.canExecuteItem(HandledContributionItem.java:839) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.access$1(HandledContributionItem.java:828) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem$3.run(HandledContributionItem.java:165) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.updateItemEnablement(HandledContributionItem.java:196) at org.eclipse.e4.ui.workbench.renderers.swt.ToolItemUpdater.updateContributionItems(ToolItemUpdater.java:39) at org.eclipse.e4.ui.workbench.renderers.swt.ToolBarManagerRenderer$8.changed(ToolBarManagerRenderer.java:367) at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:110) at org.eclipse.e4.core.internal.contexts.EclipseContext.processScheduled(EclipseContext.java:338) at org.eclipse.e4.core.internal.contexts.EclipseContext.set(EclipseContext.java:352) at org.eclipse.ui.internal.services.EvaluationService.contextEvaluate(EvaluationService.java:139) at org.eclipse.ui.internal.services.EvaluationService.addSourceProvider(EvaluationService.java:180) at org.eclipse.debug.internal.ui.contexts.DebugContextSourceProvider.<init>(DebugContextSourceProvider.java:51) at org.eclipse.debug.internal.ui.contexts.DebugWindowContextService.<init>(DebugWindowContextService.java:62) at org.eclipse.debug.internal.ui.contexts.DebugContextManager.createService(DebugContextManager.java:163) at org.eclipse.debug.internal.ui.contexts.DebugContextManager.getContextService(DebugContextManager.java:221) at org.eclipse.debug.internal.ui.commands.actions.DebugCommandService.<init>(DebugCommandService.java:76) at org.eclipse.debug.internal.ui.commands.actions.DebugCommandService.getService(DebugCommandService.java:68) at org.eclipse.debug.ui.actions.DebugCommandHandler$EnabledTarget.<init>(DebugCommandHandler.java:76) at org.eclipse.debug.ui.actions.DebugCommandHandler.getEnabledTarget(DebugCommandHandler.java:190) at org.eclipse.debug.ui.actions.DebugCommandHandler.setEnabled(DebugCommandHandler.java:172) at org.eclipse.ui.internal.handlers.HandlerProxy.setEnabled(HandlerProxy.java:233) at org.eclipse.ui.internal.handlers.E4HandlerProxy.setEnabled(E4HandlerProxy.java:132) at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:247) at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:229) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132) at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.setEnabled(HandlerServiceHandler.java:77) at org.eclipse.core.commands.Command.setEnabled(Command.java:886)
(In reply to Liviu Ionescu from comment #11) > any progress on this? No one is looking at this at the moment, but we can accept contributions: http://wiki.eclipse.org/Platform_UI/How_to_Contribute
The issue happens because DebugCommandService calls DebugCommandService.getService() while initializing which causes it to be initialized again. A possible patch: https://git.eclipse.org/r/#/c/39754/
(In reply to Snjezana Peco from comment #13) > > A possible patch: https://git.eclipse.org/r/#/c/39754/ Sorry for the wrong link. The following is a correct patch - https://git.eclipse.org/r/#/c/40373
(In reply to Marc Khouzam from comment #9) Hi Marc, I imported the plugin, I get the button in the toolbar but it is disabled ?
(In reply to Sarika Sinha from comment #15) > (In reply to Marc Khouzam from comment #9) > Hi Marc, > I imported the plugin, I get the button in the toolbar but it is disabled ? It is not for me, starting a new workspace. Looking at the events I suspect that we are missing a org.eclipse.core.commands.contexts.ContextManager.deferUpdates(boolean) call somewhere. We detect that the command is not enabled and try to show the "Chosen operation is not enabled" dialog. However, this triggers updating of the commands, which results in the stackoverflow. In 3.x this did not happen: the events were deferred and only shown once the dialog got closed.
New Gerrit change created: https://git.eclipse.org/r/46764
I have posted a very simple and localized workaround to break the recursion in DebugCommandHandler.getEnabledTarget().
Gerrit change https://git.eclipse.org/r/46764 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=aca41c340fbdc04e14f3f3de807d5cfb7244e1cb
Let's close this bug given we've released the workaround. If the problem appears again, we have to take a deeper look why it worked in 3.x but not 4.x.
*** Bug 462281 has been marked as a duplicate of this bug. ***
