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.
My build from 080904 runs out of 400MB heap. The jmap -histo shows a lot of instances of ClassTypeImpl, which, surprisingly stay in memory, even if the last debugging session is over: num #instances #bytes class name ---------------------------------------------- 8: 113700 13644000 com.sun.tools.jdi.ClassTypeImpl I can provide heap dump directly.
There remain 18 instances of JPDADebuggerImpl in memory. This is bad, because it holds the JDI objects. It looks like the problematic class is DebuggingTreeExpansionModelFilter.
Next problem is in ThreadsListener. It has static field 'instance', which holds DebuggingView and JPDADebugger.
Partially fixed, at least, one debugging session seems to be still held by DebuggingView. But previous sessions should be freed up. changeset: 101362:5e72cb5c52ae http://hg.netbeans.org/main/rev/5e72cb5c52ae
Integrated into 'main-golden', will be available in build *200809111401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/5e72cb5c52ae User: mentlicher@netbeans.org Log: #146780 - Do not hold references to finished debugger sessions.
Some more leaks are removed: changeset: 104837:6c83f5621a0a http://hg.netbeans.org/main/rev/6c83f5621a0a changeset: 104838:0451f4467d1b http://hg.netbeans.org/main/rev/0451f4467d1b There still remain some more...
Just for the reference, the leak fixed in the changeset above was caused by http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6258067
Unfortunately, calling updateUI() corrupted the UI! We have to remove that call, which, most probably, returned the memory leak back! This is really a pain to solve this! There are many places causing the leakages and many of them are magical. changeset: 104880:1914d70f4464 http://hg.netbeans.org/main/rev/1914d70f4464
Added hacks to clear Swing caches and SortAction was repaired not to hold it's menu item. The memory leak disappears if we add JTree.updateUI(). But calling that corrupts the UI, for unknown reasons. Therefore it can either look awful OR we have this memory leak. There might be some third solution, but I've already wasted enough time with this for now. http://hg.netbeans.org/main/rev/c15e7df9293f http://hg.netbeans.org/main/rev/df68b2091454
Created attachment 71056 [details] Screenshot of a reference graph - view holding visualizers and nodes.
Moving to openide for evaluation. The last memory leak seems to be in visHolder field of the TreeView. It's holding visualizer objects and transitively my nodes. But the UI is empty, tree view does not display any nodes and it has a new root set up. Calling TreeView.updateUI() clears this leak, but corrupts UI. Please evaluate.
Integrated into 'main-golden', will be available in build *200810031107* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/1914d70f4464 User: mentlicher@netbeans.org Log: #146780 - Removing updateUI() call, it corrupted the UI!!! So it looks like the memory leak is back now!
508e8e402302
Integrated into 'main-golden', will be available in build *200810040600* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/508e8e402302 User: Tomas Holy <t_h@netbeans.org> Log: #146780 #143590: Leak due to wrong cleanup of visHolder
Your fix does not seem to change anything. The leak is still there, attaching the screenshot. I'll also try to do something about it - mabe we'd have to remove the TreeView from the component hierarchy as the last resort.
Created attachment 71206 [details] The leak from TreeView
Still, TreeView.updateUI() fixes the leak, but corrupts the UI.
Removal of TreeView from top component hierarchy when there is no session running implemented. changeset 5ea53d62e53f in main details: http://hg.netbeans.org/main?cmd=changeset;node=5ea53d62e53f changeset 5ea53d62e53f in main details: http://hg.netbeans.org/main?cmd=changeset;node=5ea53d62e53f
Removal of TreeView from top component hierarchy when there is no session running implemented. changeset 7f2777abc612 in main details: http://hg.netbeans.org/main?cmd=changeset;node=7f2777abc612 changeset 5ea53d62e53f in main details: http://hg.netbeans.org/main?cmd=changeset;node=5ea53d62e53f
Integrated into 'main-golden', will be available in build *200810080201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/7f2777abc612 User: Daniel Prusa <dprusa@netbeans.org> Log: #146780: remove DebugTreeView when there is no session running a create it again when needed
Moving back to debugger, it looks like we managed to workaround all leaks in Swing and in core. You may still want to fix the problem with holding nodes from the TreeView, but we got rid of this by removing whole TreeView from the hierarchy.
After the Dan's change this should be finally fixed.
I'm reopening this, it still needs more investigation. According to automatic tests, this is still not fixed and there still remains an instance of JPDADebuggerImpl in the memory after the debugging session is finished. Pasting current reference chain discovered by the automatic test written by cyhelsky: On Windows Vista: private static java.awt.Toolkit java.awt.Toolkit.toolkit-> sun.awt.windows.WToolkit@62df1-wprops-> sun.awt.windows.WDesktopProperties@17b12bf-prChgSupport-> java.beans.PropertyChangeSupport@1be973b-children-> java.util.Hashtable@f9a239-table-> [Ljava.util.Hashtable$Entry;@152e1e9-[10]-> java.util.Hashtable$Entry@e9ab9e-next-> java.util.Hashtable$Entry@52bb54-next-> java.util.Hashtable$Entry@14b85e8-value-> java.beans.PropertyChangeSupport@1d867aa-listeners-> sun.awt.EventListenerAggregate@1f9c5fe-listenerList-> [Ljava.beans.PropertyChangeListener;@e07429-[2]-> org.openide.explorer.propertysheet.RendererFactory$1@23c4f6-this$0-> org.openide.explorer.propertysheet.RendererFactory@3b3f7b-mdl-> org.openide.explorer.propertysheet.ReusablePropertyModel@1a55e38-PROPERTY-> org.netbeans.modules.viewmodel.TreeModelNode$MyProperty@ae7876-this$0-> org.netbeans.modules.viewmodel.TreeModelNode@144709-object-> org.netbeans.api.debugger.Session@1c11080-privateLookup-> org.netbeans.api.debugger.Lookup$Compound@11a360a-l2-> org.netbeans.api.debugger.Lookup$MetaInf@1ad538-instanceCache-> java.util.HashMap@c6a507-table-> [Ljava.util.HashMap$Entry;@1115f3c-[2]-> java.util.HashMap$Entry@f2b3b5-value-> org.netbeans.modules.debugger.jpda.JPDADebuggerImpl@1119cb8) On Windows XP: private static sun.awt.AppContext sun.awt.AppContext.mainAppContext-> sun.awt.AppContext@1bd9d76-table-> java.util.HashMap@38e3c7-table-> [Ljava.util.HashMap$Entry;@c09880-[34]-> java.util.HashMap$Entry@92d902-value-> java.beans.PropertyChangeSupport@18af278-children-> java.util.Hashtable@322b4d-table-> [Ljava.util.Hashtable$Entry;@5ee932-[10]-> java.util.Hashtable$Entry@10f66d6-next-> java.util.Hashtable$Entry@52ee61-next-> java.util.Hashtable$Entry@17be73b-value-> java.beans.PropertyChangeSupport@79a624-listeners-> sun.awt.EventListenerAggregate@1382fae-listenerList-> [Ljava.beans.PropertyChangeListener;@5630ab-[2]-> org.openide.explorer.propertysheet.RendererFactory$1@18b22a7-this$0-> org.openide.explorer.propertysheet.RendererFactory@157fa46-mdl-> org.openide.explorer.propertysheet.ReusablePropertyModel@19dab0a-PROPERTY-> org.netbeans.modules.viewmodel.TreeModelNode$MyProperty@54d73a-this$0-> org.netbeans.modules.viewmodel.TreeModelNode@73ea6a-object-> org.netbeans.api.debugger.Session@1481ca2-privateLookup-> org.netbeans.api.debugger.Lookup$Compound@72d11d-l2-> org.netbeans.api.debugger.Lookup$MetaInf@fc12bc-instanceCache-> java.util.HashMap@c76b5f-table-> [Ljava.util.HashMap$Entry;@1a9ff20-[56]-> java.util.HashMap$Entry@1b153a4-value-> org.netbeans.modules.debugger.jpda.JPDADebuggerImpl@16301f4 On Linux Ubuntu and Solaris: static javax.swing.plaf.metal.MetalToolTipUI javax.swing.plaf.metal.MetalToolTipUI.sharedInstance-> javax.swing.plaf.metal.MetalToolTipUI@1759d91-tip-> javax.swing.JToolTip@18e9ae1-clientProperties-> javax.swing.ArrayTable@1b77fa7-table-> [Ljava.lang.Object;@19bdaf6-[1]-> org.netbeans.api.debugger.Session@a1fa7f-privateLookup-> org.netbeans.api.debugger.Lookup$Compound@bf0948-l2-> org.netbeans.api.debugger.Lookup$MetaInf@fb092d-instanceCache-> java.util.HashMap@180d4df-table-> [Ljava.util.HashMap$Entry;@1272a9b-[2]-> java.util.HashMap$Entry@1c68779-value-> org.netbeans.modules.debugger.jpda.JPDADebuggerImpl@1227383
Swing really creates unpredictable memory leaks. Just creating an instance of JToolTip will hold it on a strong reference! We're clearing the client property to release it from the reference chain: changeset: 105476:7a2ea1b1f191 http://hg.netbeans.org/main/rev/7a2ea1b1f191
RendererFactory should add the PropertyChangeListener to Toolkit.getDefaultToolkit() weakly. This chain creates a memory leak as can be seen from the output of the test: private static sun.awt.AppContext sun.awt.AppContext.mainAppContext-> ... [Ljava.beans.PropertyChangeListener;@5630ab-[2]-> org.openide.explorer.propertysheet.RendererFactory$1@18b22a7-this$0-> org.openide.explorer.propertysheet.RendererFactory@157fa46-mdl-> org.openide.explorer.propertysheet.ReusablePropertyModel@19dab0a-PROPERTY-> org.netbeans.modules.viewmodel.TreeModelNode$MyProperty@54d73a-this$0-> ... This is fixed in changeset: 105506:ec32d9349b40 http://hg.netbeans.org/main/rev/ec32d9349b40
According to manually taken heap dumps this seems to be fixed, the instance of JPDADebugger and all instances of com.sun.jdi.* classes are released from memory for me. Closing as fixed again, please check the tests.
Integrated into 'main-golden', will be available in build *200810091401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/7a2ea1b1f191 User: mentlicher@netbeans.org Log: #146780 - Clear the client property of JToolTip, otherwise it will remain in memory!
Integrated into 'main-golden', will be available in build *200810100201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ec32d9349b40 User: mentlicher@netbeans.org Log: #146780 - Add the PropertyChangeListener to Toolkit.getDefaultToolkit() weakly. This allows RendererFactory to be released from memory.
I tried to start three debug processes and ended them (normally, I did not stop debug session or so). jmap -histo returned log in which were also instances of mentioned clases, which should not have been present already. I paste those lines here. 89: 388 46560 com.sun.tools.jdi.ClassTypeImpl 736: 9 1512 org.netbeans.modules.debugger.jpda.JPDADebuggerImpl 1510: 19 336 [Lcom.sun.jdi.Location; 2101: 9 144 org.netbeans.modules.debugger.jpda.JPDADebuggerImpl$3 4708: 1 16 org.netbeans.modules.debugger.jpda.models.JPDAClassTypeImpl Therefore I dont think this issue can be marked as verified, but I am not sure whether to reopen it or not, so I leave it as it is for now. version and system: Product Version: NetBeans IDE 6.5 (Build 200811100001) Java: 1.6.0_10; Java HotSpot(TM) Client VM 11.0-b15 System: Linux version 2.6.24-21-generic running on i386; UTF-8; en_US (nb)
edit: I had some debug sessions even before I tried above mentioned (three simultaneous debug sessions). It seems that for each debug session, one instance of org.netbeans.modules.debugger.jpda.JPDADebuggerImpl is hanging somewhere in heap.
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.