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.
After few days of working, I've got too many editors left in memory (according to Timers/Counters). Heap dump and analysis in NetBeans Profiler revealed that they are generally held in memory through GuardedBlocksHighlighting listening on a shared instance of ProxyLookup$R (from MimeLookup). I'll keep the heap dump for a while if you need some clarification, but it is over 100MB.
Note: my build was almost a month old. I'll try to reproduce this with new build.
Ok, I'll have a look. I don't think anything has changed in GBH in the last month :-(. Could you please attach one example of the object graph showing the memory leak? Thanks.
Insane integrated into Timers/Counters window told me this: static org.netbeans.api.java.source.JavaSource.editorRegistryListener-> org.netbeans.api.java.source.JavaSource$EditorRegistryListener@13ae928-lastEditor-> org.openide.text.QuietEditorPane@10215ff-clientProperties-> javax.swing.ArrayTable@a0e822-table-> java.util.Hashtable@12cef14-table-> [Ljava.util.Hashtable$Entry;@15a5ce9-[6]-> java.util.Hashtable$Entry@869b22-value-> org.netbeans.modules.versioning.system.cvss.ui.actions.annotate.AnnotationBar@613826-editorUI-> org.netbeans.modules.editor.NbEditorUI@5dd9ac-result-> org.openide.util.lookup.ProxyLookup$R@1699e02-listeners-> javax.swing.event.EventListenerList@10d0c30-listenerList-> [Ljava.lang.Object;@5e0d03-[15]-> org.netbeans.modules.editor.oldlibbridge.GuardedBlocksHighlighting@d5a8fc-document-> org.netbeans.modules.editor.java.JavaDocument@1a78c1f-documentProperties-> org.netbeans.modules.editor.NbEditorDocument$2@d436ac-table-> [Ljava.util.Hashtable$Entry;@e7e4cc-[35]-> java.util.Hashtable$Entry@b77e65-value-> org.netbeans.modules.java.JavaDataObject@16fa319
Note that "lastEditor" is a kind of leak alone, but I'm not talking about the editor held this way. The last editor (or any currently opened editor - I've got none at the time of the heap dump) references all the visited editors through the listener on the (shared and kept in memory as long as last editor) ProxyLookup$R. I have just reproduced the same issue (the same reference chain) in current build. Try the runtime watches window, right click on the entry for any already closed editor -> find refs and give it some time (and leave enough heap).
looks simple to me..
Vito, could you please take a look on this as soon as possible? Thanks.
Should be fixed now. Could you please check that the leak's gone? Just for the record: highlighting layers generally do not need to listen on FontColorSettings changes, this is done by the infrastructure and if FCS changes the layers will be recreated. Checking in NonLexerSyntaxHighlighting.java; /cvs/editor/src/org/netbeans/modules/editor/impl/highlighting/NonLexerSyntaxHighlighting.java,v <-- NonLexerSyntaxHighlighting.java new revision: 1.2; previous revision: 1.1 done Checking in GuardedBlocksHighlighting.java; /cvs/editor/src/org/netbeans/modules/editor/impl/highlighting/GuardedBlocksHighlighting.java,v <-- GuardedBlocksHighlighting.java new revision: 1.2; previous revision: 1.1 done
Looks OK now, other leaks are probably still there.