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.
Summary: | Memory leak: Dangling (editor) TopComponents | ||
---|---|---|---|
Product: | platform | Reporter: | Svata Dedic <sdedic> |
Component: | -- Other -- | Assignee: | Petr Hrebejk <phrebejk> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | dkonecny, sdedic |
Priority: | P2 | Keywords: | PERFORMANCE |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | gif of the chain |
Description
Svata Dedic
2001-10-01 15:23:36 UTC
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. |