Community
Participate
Working Groups
Build: I20070220 Test case: 1) Open sync view with various Java projects having incoming changes 2) Capture Sleak snapshot 3) Turn off all models in the sync view, Apply 4) Turn all models back on, Apply 5) Capture Sleak diff against 2) Various icons sometimes have two or three copies created. The Java icons such as project, package, and CU, sometimes are created two or three times, with slightly different stack traces. Note, this is not technically a leak - repeating the test case multiple times doesn't create more images.
Created attachment 59788 [details] Sleak stack traces
We should switch to using the ResourceManager API to manage images so that images can be managed locally but shared globally. Givne that this is not a leak, I'm deferring it to 3.4.
Created attachment 74387 [details] Patch to Compare to improve caching This is a patch to compare that would ensure that only one of each combined icon is created. However, it does comparisons of the image data when looking for matches so I want to profile it before releasing.
I profiled it and the calls to equal didn't even show up so I think we're OK. Patch released to HEAD. Unfortunately, the fix is localized to compare so we still need to fix the duplicate images in the sync view.
Fix released to HEAD
Build id: I20070806-1800 I followed steps from the first comment and I have got leak resources. Michael could you look at it once again?
I followed the steps in the original comment and did not see a leak. There were some images after the diff but that is expected since the view is still open. There did appear to be one duplicate but that was a Java Package with a warning on it. I suspect that one was created by JDT and the other by Team. Marking as verified.
Actually, after a bit more playing around, I did find a leak. I believe this is caused by DecorationOverlayIcon which uses the base image when calculating the hashCode and equals. This is a problem since the hashCode of the image depends on the handle which gets set to 0 when the image is disposed.
Great find! I think it would be best to fix the implementation of Image equals and hashCode. Note also that unequal instances of Image become equal to each other after the images are disposed (since both their handles become zero). This isn't technically a violation of the equals/hashCode contract, but it's nevertheless confusing and likely to lead to errors for clients. Otherwise we'll need to track down and remove any use of Image as hashtable keys.
I have released a change to DecorationOverlayIcon to use an identity hash on the base image to avoid leaks for the time being. We may want to revert that based on the response to bug 199460.
(In reply to comment #10) This is also a partial fix for bug 181215.
I'm marking this as fixed since the code, as it stands, has fixed the reported issue.
I'm still able to see a leak. Below are steps I followed. I know that they don't remind the steps from the original comment, so I wouldn't mind if you decide to open a separate bug to address it. 1) Open sync view with projects having incoming and outgoing changes, conflicts are welcomed too (I had 2 ins, 50 outs and 1 conflict) 2) Capture Sleak snapshot 3) Switch to "Change Sets" model type using the drop down menu 4) Select all change sets and use "Expand All" action from the context menu 5) Switch to "Workspace" model type using the drop down menu 6) Select all change sets and use "Expand All" action from the context menu 7) Switch to "Java Workspace" model type using the drop down menu 8) Select all change sets and use "Expand All" action from the context menu 9) Switch back to "All Models" in the drop down menu 10) Turn on "Flat Presentation" 11) Turn it off 12) Turn off all models in the sync view using "Preferences...", Apply 13) Turn all models back on by clicking on "Enable All Participation Models" in the sync view 14) Capture Sleak Diff against 2). I was able to get even up to 70(!) Images in the Diff.
Reopening to investigate issue reported in previous comment.
Sorry for the late response. We will investigate the issue during 3.4M5.
I've just reproduce it on I20080205-0010 (a candidate for 3.4 M5). To make steps from comment 13 a little bit simpler: 1) Open sync view with projects having incoming, outgoing and conflicting changes. I had 53 ins, 83 outs and 15 conflicts. 2) Capture Sleak snapshot 3) Turn on "Flat Presentation" 4) Turn it off 5) Capture Sleak Diff against 2). I got 40 Images in the Diff. Unfortunately, we don't have the manpower to address it at this time, but hopefully will find some during 3.4 cycle.
Mass update - removing 3.4 target. This was one of the bugs marked for investigation (and potential fixing) in 3.4 but we ran out of time. Please ping on the bug if fixing it would be really important for 3.4, and does not require API changes or feature work.
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. If you have further information on the current state of the bug, please add it. 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.
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.
