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.

Bug 104461

Summary:	memory leak in ColoringMap.CACHE
Product:	platform	Reporter:	Quy Nguyen <quynguyen>
Component:	Text	Assignee:	Petr Nejedly <pnejedly>
Status:	RESOLVED FIXED
Severity:	blocker	CC:	mmetelka, skini
Priority:	P2	Keywords:	PERFORMANCE
Version:	6.x
Hardware:	All
OS:	All
Issue Type:	DEFECT	Exception Reporter:
Bug Depends on:
Bug Blocks:	104332, 105078, 105079
Attachments:	Heap dump reference graph

Description Quy Nguyen 2007-05-22 01:36:56 UTC

Running on JDK 1.6.0_01:

The ColoringMap.CACHE field appears to be the root of a memory leak.  To
reproduce, do:

1) Create a java project and create a JPanel form
2) Switch to the java source tab (this step may not be necessary)
3) Close the editor windows
4) Close the project
5) Use jmap or a memory profiler to get the heap dump

The org.netbeans.modules.form.FormDataNode object is still in memory and is
indirectly being held by this map.  This issue is also a problem with visual web
projects.

Comment 1 Vitezslav Stejskal 2007-05-22 03:17:06 UTC

Can you please attach the references gpraph? Thanks.

Comment 2 Quy Nguyen 2007-05-22 19:40:39 UTC

Created attachment 42659 [details]
Heap dump reference graph

Comment 3 Quy Nguyen 2007-05-22 19:41:11 UTC

Attached is a snapshot of the reference graph from the heap dump.  It shows the
ColoringMap.CACHE field reference up to the leaking NbEditorUI object.

Comment 4 Vitezslav Stejskal 2007-05-24 06:57:30 UTC

Ok, I'll have a closer look.

Comment 5 Quy Nguyen 2007-05-29 23:28:04 UTC

*** Issue 104332 has been marked as a duplicate of this issue. ***

Comment 6 Vitezslav Stejskal 2007-05-30 01:59:11 UTC

*** Issue 105083 has been marked as a duplicate of this issue. ***

Comment 7 Vitezslav Stejskal 2007-05-30 07:54:43 UTC

The EditorUI is held through its listener. The problem only happens with multi
views, eg. form editor. The reason for that is that multiviews do not call
CloneableEditor.canClose like normal editors and that calling CE.canClose has a
side effect of cleaning up the associated JEditorPane.

The normal sequence of events (as it is expected by the editor infrastructure)
is this:

1. create JEP
2. set JEP's editor kit -> kit.install(JEP)
3. use JEP
4. reset JEP's editor kit to null -> kit.deinstall(JEP)

The kit.install/deinstall methods are main hooks for the editor infrastructure
where a lot of editor stuff is added/removed. Among other things EditorUI is
created and adds/removes its listener on ColoringMap.

The above steps are what should happen and also normally happens, most of it is
done in CloneableEditor. When using multiview #4 does not happen, because nobody
calls CloneableEditor.canClose, MultiViewElements have their own special way of
telling if they can be closed. The real question I think is, why #4 is done in
CE.canClose and not for example in CE.componentClosed.

Comment 8 Petr Nejedly 2007-06-01 08:39:26 UTC

I'll try the outlined possibility.

Comment 9 Shivanand Kini 2007-06-29 03:03:07 UTC

until this gets fixed, individual classes extending CE can do the reset editorkit, to release memory.

Comment 10 Petr Nejedly 2007-07-03 16:09:07 UTC

I'm testing the proposed fix now.
BTW: There seems to be another (minor) leak related to ColoringMap.CACHE:
It uses WeakHashMap, but its values (ColoringMap) reference its (otherwise weak) keys (MimePath) through
ProxyLookup$R lookupResult -> MimePathLookup this$0 -> MiMePath mimePath.

MemoryLint's "Leaking WeakHashMap" rule discovers this problem (in several similar instances) easily.

Comment 11 Petr Nejedly 2007-07-03 16:30:14 UTC

Fixed as outlined:

openide/text/src/org/openide/text/CloneableEditor.java,v1.20