Community
Participate
Working Groups
M20120909-2000. Lots of objects are leaked in a simple close/open part scenario. Simple test case: 1. prepare a perspective with only the Navigator view open 2. reset the instance counter of your profiler 3. close the Navigator 4. reopen the Navigator ==> see many instance being leaked, e.g. 3 ToolItem(s) and 2 ToolBar(s)
Created attachment 220933 [details] Shows the leaks The leaks at the top (above HashMap / 24) should be ignored. Those instances grow (and get GCed) constantly even when nothing happens (bug 389251).
The CommandContributionItem entries and ElementReference are probably the same issue as described in the bug 389335 .
Added fix into R4_2_maintenance for HandledMenuItemImpl and ParameterizedCommand's: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=d9d9f209f7f9a8d8a0c08381ee8f8bf51279fa2c
Fixed EclipseContext leak and its related structures in R4_2_maintenance: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=bba83be0f4032360e1d8eebad230ecc55240f36e
The ToolBar leak might be related to CTabFolder#minMaxTb
Created attachment 221486 [details] Null some toolbar fields in CTF Oleg, here is a patch you can try.
Released the patch to master - we can try out tonight's nightly to see if it made a difference (I'm guessing no, but it doesn't hurt to null out the fields).
Can this be marked FIXED or still in progress?
(In reply to comment #8) > Can this be marked FIXED or still in progress? In progress.
Fixed a Color object leaked by the splash screen: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=8f25fbc4d8ff121d8cbe86c2e1e931d12998b1fb This leak is not a big deal, I am addressing it to isolate Color leaks associated with parts close / open.
Fixes leaking image from the drop-down menu button in the part stack: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=e5657ae23fa549e6dd34b30723f9189317146c99
(In reply to comment #11) > Fixes leaking image from the drop-down menu button in the part stack: > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?h=R4_2_maintenance&id=e5657ae23fa549e6dd34b30723f9189317146c99 Oops, that was wrong. Reverted.
Fixing image leak from the "shadow" image on the CTabFolder: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=33b09f270cc969502514aff47fb2125128ba5db1 I also removed caching of those images via Display.E4_SHADOW_IMAGE as it was not used, was incorrect (only one last image would have being accessible and disposed), and made code more complicated.
Oleg, did you just fix bug 379581?
(In reply to comment #7) > Released the patch to master - we can try out tonight's nightly to see if it > made a difference (I'm guessing no, but it doesn't hurt to null out the > fields). Thanks Bogdan! Using N20120926-2000, the ToolBar and related SWT items are no longer show up in the "leaks" list.
(In reply to comment #14) > Oleg, did you just fix bug 379581? Yes, indeed! Thank you!
I think this bug mostly has being fixed. In my tests only two items left: (a) a little leak in the sash rendered (opened bug 390968 as it touches aspects that I am not familiar with). This is not significant and only appears when a last part in the sash is getting repeatedly closed and re-opened. (b) a possible leaks of a single EclipseContext in the open/close part cycle. This shows up in the profiler, but I can't pin it down. This might be a profiler or VM artifact, see below. I spend a good deal of time on tracking down (b) and starting to wonder if it is real or not. - all the contexts we allocate in the scenario are getting properly disposed - the profiler shows that the "leaking" context is an empty context with no parent - I changed code removing all but one context that we allocate in the scenario. The one remaining context (PartRenderingEngine.safeCreateGui) was needed for UI to function, but it does not fit the "empty context" description above. The profiler still showed one leaking empty context. - I tracked down all references that profiler shows to the suspicious context and they aren't getting changed in the scenario; hence they can't produce the leak
> (b) a possible leaks of a single EclipseContext in the open/close part > cycle. This shows up in the profiler, but I can't pin it down. This might be > a profiler or VM artifact, see below. > > I spend a good deal of time on tracking down (b) and starting to wonder if > it is real or not. > - all the contexts we allocate in the scenario are getting properly disposed > - the profiler shows that the "leaking" context is an empty context with no > parent > - I changed code removing all but one context that we allocate in the > scenario. The one remaining context (PartRenderingEngine.safeCreateGui) was > needed for UI to function, but it does not fit the "empty context" > description above. The profiler still showed one leaking empty context. > - I tracked down all references that profiler shows to the suspicious > context and they aren't getting changed in the scenario; hence they can't > produce the leak In my profiler (OptimizeIt) it also leaks 1 EclipseContext on each open/close. The allocation trace (see attached picture) indicates that the object created in PartRenderingEngine.safeCreateGui() is note freed.
.
Created attachment 222014 [details] Context allocation trace
Created attachment 222019 [details] Reference graph
It looks like the contexts are disposed at some point but still referenced. See attached reference graph.
org.eclipse.e4.core.internal.contexts.ValueComputation objects are also still leaked.
Fixed EclipseContext leak: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=1e8f1f19c0036d01405e2041d220374a457e3bb8
Fixed ValueComputation leaks: http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?h=R4_2_maintenance&id=bcadf392c9ebf21d6a52e3fc38c0f09379db5315
I think the general situation with closing/opening parts is pretty good now (with the small issue left described in the bug 390968).
Verified using I20121030-0800 and M20121024-1600.
(In reply to comment #26) > I think the general situation with closing/opening parts is pretty good now > (with the small issue left described in the bug 390968). Verified this in N20130114-2000: much better now!
