Community
Participate
Working Groups
Extracted from bug 231175 Every image allocated by WorkbenchLabelProvider remains in use by the label provider, even after the element is no longer needed by the viewer or the element changes its label. The images are not disposed when the elements are no longer used by the viewer (fixing this would require a way for the viewer to tell the label provider when each element is no longer needed)
This is particularly a problem for the WorkbenchLabelProvider used by the Package Explorer, since that instance will probably not be disposed until the user exits the app - so all images are effectively leaked.
In our plugin we allow users to change the custom icons at runtime. The images are never released as long the labelprovider/view exists. I think this issue is a general problem existing for all viewers and labelproviders in jface. Is there any thing one can do about this? Disposing the image after firing a labelchange event doesn't seem work in all cases and results in the following stacktrace: Exception in thread "main" org.eclipse.swt.SWTException: Graphic is disposed at org.eclipse.swt.SWT.error(SWT.java:4282) at org.eclipse.swt.SWT.error(SWT.java:4197) at org.eclipse.swt.SWT.error(SWT.java:4168) at org.eclipse.swt.graphics.Image.getImageData(Image.java:1209) at org.eclipse.swt.internal.ImageList.set(ImageList.java:405) at org.eclipse.swt.internal.ImageList.add(ImageList.java:70) at org.eclipse.swt.widgets.Tree.imageIndex(Tree.java:3639) at org.eclipse.swt.widgets.Tree.wmNotifyChild(Tree.java:7347) at org.eclipse.swt.widgets.Control.wmNotify(Control.java:5534) at org.eclipse.swt.widgets.Composite.wmNotify(Composite.java:1896) at org.eclipse.swt.widgets.Control.WM_NOTIFY(Control.java:5086) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4584) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1610) at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2061) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972) at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:2425) at org.eclipse.swt.widgets.Tree.callWindowProc(Tree.java:1533) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4623) at org.eclipse.swt.widgets.Tree.windowProc(Tree.java:5937) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:2531) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3752) at swt.AbstractSWTApplication.<init>(AbstractSWTApplication.java:19) at disposetreelabelimage.TestTreeViewerImageDisposal.<init>(TestTreeViewerImageDisposal.java:11) at disposetreelabelimage.TestTreeViewerImageDisposal.main(TestTreeViewerImageDisposal.java:35) Is there any way to get informed when tree no longer needs access to the image?
I would expect that disposing of your images after the tree items have been updated would be safe.
Is there any progress with this? I don't know if this is a problem with my implementation but even when disposing images after an update notification, I sometimes receive a graphics is disposed exception. Since image don't change that often, I just live with this memory leak at the momement. Would it be possible to introduce an LabelProviderX interface like it was done for example with IDocument and IDocumentExtensionX. On this interface one could add a getImageDescriptor-Method and let the viewer manage the resource allocation. I think about something similar to the ILightweightLabelDecorator where one ImageDescriptors are used.
Heiko, in the interests of honesty I have to say that it's unlikely that this issue will be addressed barring a patch. The defect is 4 years old and has not generated more than this one defect report (which was opened by someone working on it, not from a user). If the only thing you're concerned about is the 'leak' then I suspect that you will likely have to live with it. Note that a restart will start with a 'fresh' cache so won't include the images that are no longer needed.
Thanks Eric, you are right, it's not something that seems to be big problem. My question was more for interesst whether any one cares about this memory leaks or everyone lives with this. It's realy a rare case where the users changes the images. A workaround to cleaning up the images, is to dispose them a little bit later. But as you say, it's not something that causes a out of memory or something like that. Comparing the size per image (round about 8 kb) and assuming that a user may create 1000 images during a session this is only 8 mb.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
