Details
-
Bug
-
Resolution: Fixed
-
P2
-
6u23
-
b78
-
x86
-
linux
-
Verified
Description
Another memory leak was reported to NetBeans, this time it goes through inputMethod. See attached heap dump (search for references to JTextField) and NetBeans bug http://netbeans.org/bugzilla/show_bug.cgi?id=199392
Chain of references (retyped):
sun.awt.im.InputContext.inputMethodWindowContext ->
InputMethodContext.compositionAreaHandler ->
CompositionAreaHandler.clientComponent ->
JTextField
Following is NetBeans customer inqury copied from the bug 199392:
The netbeans RCP test suite to reproduce the problem:
http://netbeans.org/bugzilla/attachment.cgi?id=108886
This bug was tested on following configuration:
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
netbeans IDE & platform 7.0
OS: Linux kernel version 2.6.38
Java L&F: metal
Bug description:
In the attachment is simple test suite with test module. The test module
contains one top component which is automatically opened on the startup of the
RCP application. The top Component contains JTextField and JFormattedTextField.
After the application start click with mouse to the JTextField or to the
JFormattedTextField. When the text field has focus close the top component.
After closing the top component click on the memory panel in order to invoke
the garbage collection.
After the garbage collection analyze the java heap with jmap and jhat utils
(see the script java_mem_leak.sh in the attachment). You can see that the
MemLeakTopComponent is still on the heap. When you check the root set
references you can see that the cause is the reference from
sun.awt.X11.XInputMethod field needResetXICClient to the jTextField or
JFormattedTextField (see the atached memleak.html page).
I suppose that the needResetXICClient field is not correctly cleared when the
MemLeakTopComponent is closed. When you open several MemleakTopComponents and
close them all, only the last top component remains in memory.
Chain of references (retyped):
sun.awt.im.InputContext.inputMethodWindowContext ->
InputMethodContext.compositionAreaHandler ->
CompositionAreaHandler.clientComponent ->
JTextField
Following is NetBeans customer inqury copied from the bug 199392:
The netbeans RCP test suite to reproduce the problem:
http://netbeans.org/bugzilla/attachment.cgi?id=108886
This bug was tested on following configuration:
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
netbeans IDE & platform 7.0
OS: Linux kernel version 2.6.38
Java L&F: metal
Bug description:
In the attachment is simple test suite with test module. The test module
contains one top component which is automatically opened on the startup of the
RCP application. The top Component contains JTextField and JFormattedTextField.
After the application start click with mouse to the JTextField or to the
JFormattedTextField. When the text field has focus close the top component.
After closing the top component click on the memory panel in order to invoke
the garbage collection.
After the garbage collection analyze the java heap with jmap and jhat utils
(see the script java_mem_leak.sh in the attachment). You can see that the
MemLeakTopComponent is still on the heap. When you check the root set
references you can see that the cause is the reference from
sun.awt.X11.XInputMethod field needResetXICClient to the jTextField or
JFormattedTextField (see the atached memleak.html page).
I suppose that the needResetXICClient field is not correctly cleared when the
MemLeakTopComponent is closed. When you open several MemleakTopComponents and
close them all, only the last top component remains in memory.
Attachments
Issue Links
- relates to
-
JDK-8023814 Test java/awt/im/memoryleak/InputContextMemoryLeakTest.java fails
- Resolved