Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 104461 - memory leak in ColoringMap.CACHE
memory leak in ColoringMap.CACHE
Product: platform
Classification: Unclassified
Component: Text
All All
: P2 (vote)
: 6.x
Assigned To: Petr Nejedly
: 104332 105083 (view as bug list)
Depends on:
Blocks: 104332 105078 105079
  Show dependency treegraph
Reported: 2007-05-22 01:36 UTC by Quy Nguyen
Modified: 2008-12-22 13:39 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT

Heap dump reference graph (145.10 KB, image/jpeg)
2007-05-22 19:40 UTC, Quy Nguyen

Note You need to log in before you can comment on or make changes to this bug.
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
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:


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo