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.
While working on issue 143590 (and after applying its patch http://www.netbeans.org/nonav/issues/showattachment.cgi/67131/X.diff) I get following memory leak: private static final java.util.Map org.netbeans.api.java.source.JavaSource.finishedRequests-> java.util.WeakHashMap@12d0266-table-> [Ljava.util.WeakHashMap$Entry;@5b5669-[6]-> java.util.WeakHashMap$Entry@f54356-value-> java.util.LinkedList@f1ba4b-header-> java.util.LinkedList$Entry@b93dfa-next-> java.util.LinkedList$Entry@1a58b49-element-> org.netbeans.api.java.source.JavaSource$Request@f213e4-javaSource-> org.netbeans.api.java.source.JavaSource@7feca0-classpathInfo-> org.netbeans.api.java.source.ClasspathInfo@af516d-srcClassPath-> org.netbeans.api.java.classpath.ClassPath@745d25-impl-> org.netbeans.spi.java.project.support.ClassPathProviderMerger$ProxyClassPathImplementation@fdd079-mainProvider-> org.netbeans.modules.java.j2seproject.classpath.ClassPathProviderImpl@4dab8c-sourceRoots-> org.netbeans.modules.java.api.common.SourceRoots@163b86f-helper-> org.netbeans.modules.java.api.common.ant.UpdateHelper@d070e9-updateProject-> org.netbeans.modules.java.j2seproject.UpdateProjectImpl@1405b99-project-> org.netbeans.modules.java.j2seproject.J2SEProject@1506a1e What makes me wonder is why "finishedRequests" is a weakhashmap, when its value JavaSource$Request@f213e4 seems to have strong reference back to its key "javaSource"? Shall not the finishedRequest list be made an instance variable of JavaSource, anyway?
Actually related to what we discussed - if the events won't reach the factories correctly, the factories will not fire correctly their events, and so the tasks will never be unregistered. Given that the tasks are the only thing that keeps the JavaSource in memory (to my knowledge), and that the only thing that keeps the tasks in memory is (or should be unless we want to leak *a lot*) the JavaSource, simply making it "all weak" is very likely to completely break Java support. BTW: this seems like a "last one" problem - wouldn't it make sense to make the test immune to the "last one" problem (opening a .txt file in the editor should be enough), and concentrate our efforts on hunting cumulative leaks?
Re. events - if you know what is wrong, please assign to person that generates the events incorrectly. I do not know anything about that. Re. "last" - I am quite fine with fixing this problem by changing the test to do some additional actions. Again, feel free to modify it to open some new java file, parse it, etc. Tricks are allowed to satisfy our main goal: be able to successfully call assertProjects() after some set of UI operations.
> Re. events - if you know what is wrong, please assign to person that generates the events incorrectly. I do not know > anything about that. Sounds reasonable. Honzo, Who does not fire events correctly? > Re. "last" - I am quite fine with fixing this problem by changing the test to do some additional actions. Again, feel > free to modify it to open some new java file, parse it, etc. Tricks are allowed to satisfy our main goal: be able to > successfully call assertProjects() after some set of UI operations. If the fix of this small memory leak is risky, this bug is wantfix. Anyway we can help you with some workarounds in tests. Come and ask Honza how to do it yourself ;)
Do you have some data to justify your attempt to call this "small memory leak"? Unless you provide them, let's treat this report as regular memory leak, please.
I take "small" back. Data on justification of impact and how big is this memory leak is up to you, Jardo ;) i just wanted to say, that fixing of memory leak which is not big (and I bet, that this issue will be p2 if the memory leak is big) and not cumulative with possible negative impact on quality is something which we don't want to do.
My trouble is that without this issue being fixed, I am not able to eternally confirm that the leak is not cumulative. I need to fix all leaks regardless of their size before I can write test and make it part of commit validation. In this sense the leak "blocks developer progress", but I do not want to make it P2 now, as the goal of preventing leaks of projects is just P3 for us in 6.5 release.
Overtake.
@jtulach: Is this issue still valid? jlahoda in our discussion said it should be invalid yet. Please, can you verify this issue again?
Should you have run the test yourself instead of playing with INCOMPLETE keyword, you would find out that leak through "java source" still exists: private static java.util.Collection org.netbeans.modules.parsing.impl.Schedulers.taskSchedulers-> java.util.Collections$UnmodifiableRandomAccessList@8b2aba-list-> java.util.ArrayList@1391fc2-elementData-> [Ljava.lang.Object;@1768386-[0]-> org.netbeans.modules.parsing.impl.CurrentDocumentScheduler@18906e4-source-> org.netbeans.modules.parsing.api.Source@95d96-cache-> org.netbeans.modules.parsing.impl.SourceCache@1f65cee-parser-> org.netbeans.modules.java.source.parsing.JavacParser@4babb8-cpInfo-> org.netbeans.api.java.source.ClasspathInfo@e2bc6e-srcClassPath-> org.netbeans.api.java.classpath.ClassPath@1bfe8c0-impl-> org.netbeans.spi.java.project.support.ClassPathProviderMerger$ProxyClassPathImplementation@13d8c61-mainProvider-> org.netbeans.modules.java.api.common.classpath.ClassPathProviderImpl@18ccc5e-helper-> org.netbeans.spi.project.support.ant.AntProjectHelper@1931e4-state-> org.netbeans.api.project.ProjectManager$ProjectStateImpl@3c304a-p-> org.netbeans.modules.java.j2seproject.J2SEProject@1fc0932
After my changeset http://hg.netbeans.org/ergonomics/rev/22bd852800e3 there seems to be only one last leak (again through "java source"): static final org.openide.util.Lookup org.netbeans.modules.project.ui.actions.LookupSensitiveAction$LastActivatedWindowLookup.INSTANCE-> org.netbeans.modules.project.ui.actions.LookupSensitiveAction$LastActivatedWindowLookup@1ff7a62-reg-> org.netbeans.core.windows.RegistryImpl@faff12-support-> java.beans.PropertyChangeSupport@102aae6-listeners-> sun.awt.EventListenerAggregate@6edbc7-listenerList-> [Ljava.beans.PropertyChangeListener;@398a1e-[3]-> org.netbeans.modules.parsing.impl.SelectedNodesScheduler$AListener@149293d-this$0-> org.netbeans.modules.parsing.impl.SelectedNodesScheduler@1c10172-source-> org.netbeans.modules.parsing.api.Source@15f0bad-cache-> org.netbeans.modules.parsing.impl.SourceCache@494403-parser-> org.netbeans.modules.java.source.parsing.JavacParser@10f4211-cpInfo-> org.netbeans.api.java.source.ClasspathInfo@a1d3e9-srcClassPath-> org.netbeans.api.java.classpath.ClassPath@4a0c21-impl-> org.netbeans.spi.java.project.support.ClassPathProviderMerger$ProxyClassPathImplementation@c76b3c-classPaths-> [Lorg.netbeans.spi.java.classpath.PathResourceImplementation;@18f5229-[0]-> org.netbeans.spi.java.project.support.ClassPathProviderMerger$ProxyFilteringCPI@ce5cf-classpath-> org.netbeans.api.java.classpath.ClassPath@1842212-impl-> org.netbeans.modules.java.api.common.classpath.SourcePathImplementation@1811196-sourceRoots-> org.netbeans.modules.java.api.common.SourceRoots@699803-helper-> org.netbeans.modules.java.api.common.ant.UpdateHelper@e805a7-updateProject-> org.netbeans.modules.java.j2seproject.UpdateProjectImpl@37d8fa-project-> org.netbeans.modules.java.j2seproject.J2SEProject@858c07
Jan, as negotiated by Víťa and Moonko, I will now be helping you to fix this issue.
I have identified several places in the jet area that were holding the last project: -cache in CodeStylePreferences: the cache uses WeakHashMap, but after the project is closed, no-one touched the cache (understandably), and so some values in the cache have survived. -BeansPanel in beans module held itself statically -Schedulers do not support "unscheduling" (the last scheduled source is held forever) I have fixed the first two problems: jet-main b4b625ba8e7c I have contacted Hanz with a possible fix to the third problem. Anyway, after fixing these problems, the test sometimes passes, sometimes not. Below, I will list the dumps that I have seen. Once, I have even seen that insane was not able to find who is holding the reference. Before enabling the test, please make sure it is very stable - parallel integration does not work well with unstable tests. private static org.netbeans.core.ide.ServicesTab org.netbeans.core.ide.ServicesTab.DEFAULT-> org.netbeans.core.ide.ServicesTab@1ef1245-parent-> javax.swing.JPanel@d94cd8-component-> [Ljava.awt.Component;@18e9635-[0]-> org.netbeans.modules.project.ui.ProjectTab@1b29b56-btv-> org.netbeans.modules.project.ui.ProjectTab$ProjectTreeView@a8253a-searchTextField-> org.openide.explorer.view.TreeView$8@ae1008-keyListener-> org.openide.explorer.view.TreeView$ExplorerTree$SearchFieldListener@3231ed-results-> java.util.ArrayList@d42c65-elementData-> [Ljava.lang.Object;@eb3254-[1]-> javax.swing.tree.TreePath@d12eb4-lastPathComponent-> org.openide.explorer.view.VisualizerNode@da853b-node-> org.netbeans.modules.project.ui.ProjectsRootNode$BadgingNode@1b34c53-pair-> org.netbeans.modules.project.ui.ProjectsRootNode$ProjectChildren$Pair@d3a7bd-project-> org.netbeans.modules.java.j2seproject.J2SEProject@14d160c private static sun.awt.im.InputContext sun.awt.im.InputContext.inputMethodWindowContext-> sun.awt.im.InputMethodContext@1dc21e5-compositionAreaHandler-> sun.awt.im.CompositionAreaHandler@1e439f-clientComponent-> org.openide.explorer.view.TreeView$ExplorerTree@1d65df9-this$0-> org.netbeans.modules.project.ui.ProjectTab$ProjectTreeView@236c8b-searchTextField-> org.openide.explorer.view.TreeView$8@11aeef1-keyListener-> org.openide.explorer.view.TreeView$ExplorerTree$SearchFieldListener@1488dd9-results-> java.util.ArrayList@122ea66-elementData-> [Ljava.lang.Object;@1a8e1e2-[1]-> javax.swing.tree.TreePath@195ae70-lastPathComponent-> org.openide.explorer.view.VisualizerNode@1350500-node-> org.netbeans.modules.project.ui.ProjectsRootNode$BadgingNode@117e412-pair-> org.netbeans.modules.project.ui.ProjectsRootNode$ProjectChildren$Pair@1fa26c5-project-> org.netbeans.modules.java.j2seproject.J2SEProject@14c4f70 private static java.util.Map org.netbeans.modules.project.ui.ProjectTab.tabs-> java.util.HashMap@17dbcb6-table-> [Ljava.util.HashMap$Entry;@4835ee-[10]-> java.util.HashMap$Entry@31fd76-value-> org.netbeans.modules.project.ui.ProjectTab@a68033-btv-> org.netbeans.modules.project.ui.ProjectTab$ProjectTreeView@1585cf8-visHolder-> org.openide.explorer.view.TreeView$VisualizerHolder@30aac8-map-> java.util.HashMap@9ac4f2-table-> [Ljava.util.HashMap$Entry;@18b21e5-[13]-> java.util.HashMap$Entry@82f48-key-> org.openide.explorer.view.VisualizerChildren@1f0c908-snapshot-> org.openide.nodes.EntrySupport$Default$DefaultSnapshot@1c24d52-holder-> org.openide.nodes.ChildrenArray@17aad28-map-> java.util.WeakHashMap@57a75a-table-> [Ljava.util.WeakHashMap$Entry;@b8efe9-[0]-> java.util.WeakHashMap$Entry@3f668d-value-> java.util.LinkedList@fe34e6-header-> java.util.LinkedList$Entry@10db748-next-> java.util.LinkedList$Entry@130acca-element-> org.netbeans.modules.project.ui.ProjectsRootNode$BadgingNode@1523ef9-pair-> org.netbeans.modules.project.ui.ProjectsRootNode$ProjectChildren$Pair@12d651-project-> org.netbeans.modules.java.j2seproject.J2SEProject@14c4f70
Thanks for fixing the issues in editor. The three remaining problems seem to be in explorer. So as soon as the one remaining Hanz's problem is fixed, we can reassign to Tomáš Holý, I guess. Tomáši, can you think of fixing SearchFieldListener to clean paths that are no longer present in the tree? Do you want to solve it as part of this bug or do you want me to report some new one?
SearchFieldListener fixed in core-main #c5a62846be23
Integrated into 'main-golden', will be available in build *200908242212* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/c5a62846be23 User: Tomas Holy <t_h@netbeans.org> Log: #143593: clear search results on search field close
Created attachment 86868 [details] Patch that eliminates the leak in parsing API. Hanzi, please evaluate
I have already pushed a change (to jet-main) that should eliminate the Scheduler's references - however, the parallel integration builders where not able to build a daily build with this change since Friday.
Integrated into 'main-golden', will be available in build *200909021401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/c789a7a8ea30 User: Jan Lahoda <jlahoda@netbeans.org> Log: #143593: making sure the standard schedulers clear there internal structures when the last document is closed.
Jan's changes are in, so I am enabling the test: core-main#52f3cfe42459 If you see the testGCProjects fail on your builders, please report a bug for me and feel free to temporarily backout 52f3cfe42459 so your integrations are not prevented.
Integrated into 'main-golden', will be available in build *200909032054* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/52f3cfe42459 User: Jaroslav Tulach <jtulach@netbeans.org> Log: The bug #143593 is fixed, the testGCProjects seems to pass for me and Tom�? Hol�, so let's enable the test and see if it passes for everyone.