JDK-4506928 : Memory leak caused by java.awt.FileDialog
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2001-09-25
  • Updated: 2017-03-29
  • Resolved: 2002-07-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.3.1_05 05Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
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