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've worked with NetBeans for a small while. I've opened two java sources in the editor (they docked into the same frame), closed them (X icon on frame's title), then opened another file and closed it. I've checked all available workspaces, none of them held Editor mode visible. The Editor UI components are, however, still strongly reachable from the rootset. Dump from HAT follows: --> sun.awt.motif.MToolkit@0xe8d23808 (48 bytes) (field eventListener:) --> java.awt.Toolkit$ToolkitEventMulticaster@0x90d22409 (16 bytes) (field a:) --> java.awt.Toolkit$ToolkitEventMulticaster@0x402a9008 (16 bytes) (field a:) --> java.awt.Toolkit$ToolkitEventMulticaster@0x70c8ec09 (16 bytes) (field b:) --> java.awt.Toolkit$SelectiveAWTEventListener@0x80b4c008 (32 bytes) (field listener:) --> org.netbeans.core.windows.frames.SplitContainerImpl@0x28b20209 (440 bytes) (field tcs2Weights:) --> java.util.HashMap@0xa8940209 (48 bytes) (field table:) --> Instance of [Ljava.util.HashMap$Entry;@0x90940209 (60 bytes) (Element 12 of Instance of [Ljava.util.HashMap$Entry;:) --> java.util.HashMap$Entry@0x90b42409 (24 bytes) (field key:) --> org.netbeans.modules.java.JavaEditor$JavaEditorComponent@0xd0de6709 (408 bytes) (field obj:) --> org.netbeans.modules.java.JavaDataObject@0xc0732209 (104 bytes) (field parserGlue:) --> org.netbeans.modules.java.JavaParserGlue@0x984b2308 (64 bytes) (field swingElementMap:) --> java.util.WeakHashMap@0xd0931109 (32 bytes) (field hash:) --> java.util.HashMap@0xc8921109 (48 bytes) (field table:) --> Instance of [Ljava.util.HashMap$Entry;@0x80921109 (300 bytes) (Element 22 of Instance of [Ljava.util.HashMap$Entry;:) --> java.util.HashMap$Entry@0x58661109 (24 bytes) (field value:) --> org.netbeans.modules.java.JavaParserGlue$TextElement@0xf0671109 (24 bytes) (field myElement:) --> org.openide.src.ClassElement@0x4096c250 (24 bytes) (field impl2:) --> org.netbeans.modules.java.model.ClassElementImpl@0xb095c250 (104 bytes)
Raising priority, important.
Reassigned to Ales, famous memory leak hunter :-)
I confirm this issue. There is yet another root set reference: --> sun.awt.motif.MToolkit@0x0060c1b0 (48 bytes) (field eventListener:) --> java.awt.Toolkit$ToolkitEventMulticaster@0x016d5f58 (16 bytes) (field b:) --> java.awt.Toolkit$SelectiveAWTEventListener@0x016c84c0 (32 bytes) (field listener:) --> org.netbeans.core.windows.frames.SplitContainerImpl@0x016b3410 (440 bytes) (field contentPane:) --> org.netbeans.core.windows.frames.PerimeterPane@0x016b3858 (336 bytes) (field components:) --> java.util.HashMap@0x016b3cb8 (48 bytes) (field table:) --> Instance of [Ljava.util.HashMap$Entry;@0x016b3cf8 (20 bytes) (Element 4 of Instance of [Ljava.util.HashMap$Entry;:) --> java.util.HashMap$Entry@0x016c0628 (24 bytes) (field value:) --> org.netbeans.modules.java.JavaEditor$JavaEditorComponent@0x012c6ac8 (408 bytes)
And this is another: --> org.netbeans.core.windows.RegistryImpl@0x00b12060 (40 bytes) (field support:) --> java.beans.PropertyChangeSupport@0x00b12080 (24 bytes) (field listeners:) --> java.util.Vector@0x014ad638 (24 bytes) (field elementData:) --> Instance of [Ljava.lang.Object;@0x01350578 (320 bytes) (Element 51 of Instance of [Ljava.lang.Object;:) --> org.netbeans.modules.editor.NbEditorUI$SystemActionUpdater@0x00f09850 (40 bytes) (field this$0:) --> org.netbeans.modules.editor.NbEditorUI@0x00f10ac0 (208 bytes) (field glyphGutter:) --> org.netbeans.editor.GlyphGutter@0x029ea650 (392 bytes) (field doc:) --> org.netbeans.modules.editor.NbEditorDocument@0x01eea320 (176 bytes)
Window system's issues fixed and committed. Passing to editor to fix the last dump
Svata, I'm working on editor part of the problem. Could you or somebody from your team fix the reference from org.netbeans.modules.java.JavaEditor$JavaEditorComponent? Thanx, David
Editor part of the problem was just fixed as issue 16427. Moving to the java module where the last reference is hold.
JavaEditorComponent is *the* dangling TopComponent - I don't see references to ther TopComps down the chain
No further reference chains. I assume the bug is fixed.
Svata, I just updated all my source and built them and tried it with OptimizedIt and I still can see there some references. Am I doing something wrong? I started build wiht clean userdir. Then I removed almost all modules apart from: Editor [org.netbeans.modules.editor/1 1.8 ${buildnumber}] IDE Core [org.netbeans.core/1 1.1] Java Source Files [org.netbeans.modules.java/1 1.7 200110250937] Javadoc [org.netbeans.modules.javadoc/1 1.7 200110250937] Projects [org.netbeans.modules.projects/1 1.7 200110250937] Sourceless Java Classes [org.netbeans.modules.clazz/1 1.8 200110250937] (othwerwise I had problems with OptimizeIt) and I restarted the IDE with OptimizeIt. Then I keep opening/closing three java files and the result is after 10-15 opening that 4 references are still hold. They look very similar and I will attach screenshot of one of them to this issue. It does not look like problem in Java module, but rather in Window system. Reassign if necessary. Thanx, David
Created attachment 3141 [details] gif of the chain
Reassigning to Dafe -- the reference comes from window system. I'll try to get more info from HAT today (BTW it happened in MDI mode, I've tested it in SDI last week).
Petr, please fix this bug. You know how to use OptimizeIt :-)
I investigated this bug and I think guys are right it is fixed now. I tested it using OptimizeIt, Hat and printlns in constructor and finalize() methods of the objects. The conclusion is that you can't allways trust OptimizeIt. It sometimes shows objects refernced by WeakReferences and finalizer only. However if you encounter the memory leak again please feel free to reopen this bug.
Resolved for 3.4.x or earlier, no new info since then -> verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.