United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4506928 : Memory leak caused by java.awt.FileDialog

Details
Type:
Bug
Submit Date:
2001-09-25
Status:
Resolved
Updated Date:
2002-10-31
Project Name:
JDK
Resolved Date:
2002-07-18
Component:
client-libs
OS:
windows_2000
Sub-Component:
java.awt
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.3.1_05 (05)

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description

Name: nt126004			Date: 09/25/2001


java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)

This bug occurs in HotSpot and Classic modes. It also appears in at least the
following versions:



Steps to reproduce:

1. Create a java.awt.FileDialog.
2. Show it.
3. Close it.
4. Garbage collect many times.

The FileDialog is never garbage collected. It is being held by two JNI
references. When these steps are repeated, additional FileDialog objects are
leaked.

The memory leak of the FileDialog object itself is not too severe, however it
holds a reference to its parent Frame which is probably using much more memory.
This leak was causing our application to leak several megabytes of heap per
occurrence.

I can provide you with a simple NetBeans project that demonstrates this leak
and an OptimizeIt snapshot that shows the JNI references that are preventing
garbage collection of the FileDialog objects and their parents.
(Review ID: 132073) 
======================================================================

                                    

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.3.1_05
1.4.0_03
1.4.1_02
mantis

FIXED IN:
1.3.1_05
1.4.0_03
1.4.1_02
mantis

INTEGRATED IN:
1.3.1_05
1.4.0_03
1.4.1_02
mantis


                                     
2004-06-14
WORK AROUND



Name: nt126004			Date: 09/25/2001


Customer Workaround:
The impact of the leak can be minimized by creating a hidden Frame that is
reused solely for the purpose of making it the parent of FileDialog objects.
The FileDialog objects will still leak, but they will all have the same
inexpensive parent Frame. This approach has one side-effect... it causes the
screen to flicker when the dialog is displayed and also when you navigate into
the first directory.

JFileChooser in JRE 1.3.x has significant memory leaks and is not network-
friendly and therefore is not an acceptable alternative. The JFileChooser in
JRE 1.4-beta leaks even worse.
======================================================================
                                     
2004-06-11
EVALUATION

This is a duplicate of 4495338
###@###.### 2001-09-25

Still reproducable on Merlin B83 Win32.
###@###.### 2001-10-19

This bug is due to the local references not being deleted inside AwtFileDialog::Show() method. They are dependant on parent of FileDialog and keep the parent from being garbage collected.
###@###.### 2002-05-21
                                     
2002-05-21
SUGGESTED FIX

Explicitely delete local references in AwtFileDialog::Show method.
See diffs below.
jpsesvr:44%  diff FileDialog.cpp1 awt_FileDialog.cpp
126d125
<     jobject fileFilter = NULL;
177c176
<         fileFilter = env->GetObjectField(peer,
---
>     jobject fileFilter = env->GetObjectField(peer,
235d233
< 
237,244d234
< 
<         env->DeleteLocalRef(target);
<         env->DeleteLocalRef(parent);
<         env->DeleteLocalRef(title);
<         env->DeleteLocalRef(directory);
<         env->DeleteLocalRef(file);
<         env->DeleteLocalRef(fileFilter);
< 
252,258d241
<     env->DeleteLocalRef(target);
<     env->DeleteLocalRef(parent);
<     env->DeleteLocalRef(title);
<     env->DeleteLocalRef(directory);
<     env->DeleteLocalRef(file);
<     env->DeleteLocalRef(fileFilter);
< 
###@###.### 2002-05-21
                                     
2002-05-21



Hardware and Software, Engineered to Work Together