Community
Participate
Working Groups
For each launch that terminates and is removed, two console actions are leaked (which also keep a fair bit of the previous launch session in memory). Test case: Ran a program to termination. Removed the program via the Debug view ConsoleTerminateActionDelegate and ConsoleRemoveAllTerminatedActionDelegate leaked per launch. The reference that is keeping them in memory is that addition as selection changed listeners. But I don't understand why the dispose is not freeing them up....?
These actions changed recently to delegates as we migrated to use the action contribution story supported by the workbench. Needs investigation.
Fixed in TextConsolePage. I was disposing the menu instead of the menu manager. Please see if this helps.
Please verify, Darin (S).
Still leaking...
I believe this is a flaw in the ViewPluginAction. We contribute two actions to the TextConsole via the viewerContribution. TextConsoles come and go for each launch. These actions contributed to the view cannot be GC'd as the ViewPluginAction adds itself as a selection listener for the part but there is no mechanism or calls to remove these actions as listeners when the part goes away. Since PluginAction superclass caches the selection this can results in debug objects retained in memory.
Actually the debug objects are kept around by our actions' cache of the selection of the debug view. I changed AbstractDebugActionDelegate to null out all state on dispose...helps with the amount of leakage.
Sorry, can't get to this for M4, but will investigate for M5.
With us nulling out the selection the leak is pretty small
Deferring.
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
Will look at this performance issue in M7.
*** Bug 84282 has been marked as a duplicate of this bug. ***
> We contribute two actions to the TextConsole via the viewerContribution. Darin, can you give a bit more detail here? viewerContribution lets you contribute to a specific context menu. I assume in this case that you're contributing to the menu of the console page within the view. For the case here, is the view as a whole going away, or just the page?
Here's our plugin XML. We contribute the actions to a specific context menu via its targetID. Only the page is going away, not the view. As we launch many processes, the console view remains open, and pages within the view come and go. <extension point="org.eclipse.ui.popupMenus"> <viewerContribution targetID="org.eclipse.debug.ui.ProcessConsoleType.#ContextMenu" id="org.eclipse.debug.ui.processConsoleContextMenu"> <action label="%RemoveAllTerminatedAction.label" tooltip="%RemoveAllTerminatedAction.tooltip" icon="icons/full/elcl16/rem_all_co.gif" class="org.eclipse.debug.internal.ui.actions.RemoveAllTerminatedAction" menubarPath="additions" id="org.eclipse.debug.ui.consoleRemoveAllTerminatedAction"/> <action label="%TerminateAction.label" tooltip="%TerminateAction.tooltip" icon="icons/full/elcl16/terminate_co.gif" class="org.eclipse.debug.internal.ui.views.console.ConsoleTerminateActionDelega te" menubarPath="additions" id="org.eclipse.debug.ui.consoleTerminateAction"/> </viewerContribution> </extension>
(cc'ing Kim since this involves registry stuff) In ViewerActionBuilder.createActionDescriptor, the action is hooked up as a selection listener on the given ISelectionProvider: if (provider != null) { PluginAction action = desc.getAction(); provider.addSelectionChangedListener(action); } Since the action doesn't know the selection provider, it has no way of unregistering itself later. Might be better for the contribution (BasicContribution and subclasses) to register/deregister itself with the selection provider, and pass the notification on to its actions.
ViewerContribution already knows the selection provider (passed in its constructor).
Cleaned up the dispose logic for ViewerContribution and friends. The action was also being leaked due to a listener on the part's selection service. This leak has been fixed too, but it should not even be doing this. See bug 90373.
Verified in I20050513-0010 that no ViewPluginActions are getting leaked by launching a target. OptimizeIt shows the two ViewPluginActions being created for the viewerContributions to the TextConsolePage's menu, then being released when the launch is removed.
