This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I see in profiler that each invocation of Clean and Build action on a J2SE project leaves 5 instances of SimpleLookup$SimpleResult on heap. I am attaching 5 screenshots of OptimizeIt window showing reference paths for the leaked instances. 4 of them were created from code in GlobalActionContextImpl.blickActionMap(), the fifth one comes from a different code - see the allocation path on the screenshots.
Created attachment 27200 [details] OptimizeIt screenshot 1
Created attachment 27201 [details] OptimizeIt screenshot 2
Created attachment 27202 [details] OptimizeIt screenshot 3
Created attachment 27203 [details] OptimizeIt screenshot 4
Created attachment 27204 [details] OptimizeIt screenshot 5
BTW, there are also other lookup objects leaking. See another screenshot - list of leaking instances after 3 invocations of Clean and Build (thus the +15 leaking SimpleLookup$SimpleResult objects). Let me know if you need more information.
Created attachment 27205 [details] List of leaking instances after 3 Clean and Build invocations
I'd like to know why the problem is supposed to be in lookup? Can't you reassign Tonda to someone who really holds the leak? For example on of the reference roots in the picture?
Pardon my ignorance. But I just wanted the issue to be assigned to you, because I saw in CVS annotations that you were the last one to do changes to the method GlobalActionContextImpl.blickActionMap(). If you disagree, assign to me, and I will try to find another owner.
But blickActionMap is not in openide/lookup!
lookup is not responsible for what people do with it, nor where they store its results. For example having HashMap called lookups is not very likely what EditorContextImpl shall do.
EditorContextImpl has to store 3 lookup results so that it can listen on them. They were stored in a hash map, now they are in class fields - but the result is the same. The single EditorContextImpl instance holds just three lookup results. From an analysis in OptimizeIt we did with Tonda it looks like the problem is really in GlobalActionContextImpl.blickActionMap() where a new ProxyLookup is created, which clones the orig. lookup or someweher around that stack... The EditorContextImpl itself does not seem to create the leak. Moving to openide/windows for evaluation, there's the GlobalActionContextImpl defined.
Talked about this with Yarda. Reassigning to him.
The code has been rewritten a bit recently, and today when I tried to invoke "clean & build" few times and the amount of results stayed constant - 7 all the time.
Unfortunatelly, the problem did not disappear. See the following two OptimizeIt screenshots.
Taken with build 200512152030.
Created attachment 27886 [details] Cumulated instance after one invocation of Clean & Build action
Created attachment 27887 [details] Cumulated instances after two invocations of Clean & Build action
INSANE shows the following reference path for one of the instances of ProxyLookup$R: org.netbeans.modules.project.ui.actions.Actions.RENAME_PROJECT-> org.netbeans.modules.project.ui.actions.ProjectAction@186bf64-> [Lorg.openide.util.Lookup$Result;@eb6305-> org.openide.util.lookup.SimpleProxyLookup$ProxyResult@13af36f-> org.openide.util.lookup.ProxyLookup$R@db0a6f-> javax.swing.event.EventListenerList@11f0e1d-> [Ljava.lang.Object;@5a11ba-> org.openide.util.lookup.ExcludingLookup$R@1ae9c34-> org.openide.util.lookup.ProxyLookup$R@af5747 The ExcludingLookup$R seems to be listening on a result of the original lookup. Perhaps the blickActionMap() should first clean the listener paths for the previous temporary lookup before it creates new temporary lookup?
Closed as duplicate. A new one has fixed attachments due to this problem: issue #70577 *** This issue has been marked as a duplicate of 70578 ***