JDK-6990010 : Simple swing app leaks memory when a display mode change occurs
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6u21,7,8u40
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_7
  • CPU: x86
  • Submitted: 2010-10-06
  • Updated: 2015-05-13
  • Resolved: 2015-05-13
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.
JDK 9
9Resolved
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b17, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
I am running with multiple monitors.  I reproduced this by having the Java application on the same monitor that I changed the resolution on.

A DESCRIPTION OF THE PROBLEM :
When you have a simple swing application running and the display mode changes for any reason the swing application leaks between 5 and 10MB of memory.

The simplest way to observe this is to switch back and forth between two screen resolutions.

This is similar to Bug ID 6209673 which is reported to be fixed.  The reproduction steps here are slightly simplified to use a change in resolution to trigger the issue.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Run the attached program (taken from Bug ID 6209673) on Windows.
2. Maximize the application.
3. Open task manager and observe the memory being used by the Java application.
4. Open Display Properties.
5. Switch the resolution to some other resolution.
6. Observe the memory increase by between 5 and 10MB.





EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The Java application should not leak memory when the display mode changes.
ACTUAL -
The Java application leaked between 5 and 10MB of memory with each display mode change.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Eventually once you leak enough memory to go over the allocated Java heap space you get the typical out of memory error.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.Container;
import java.awt.BorderLayout;
import javax.swing.JFrame;
import javax.swing.JLabel;

public class GraphicLeak
{
    public static void main(String[] args)
    {
        JFrame frm = new JFrame("Memory leak");
        Container cp = frm.getContentPane();
	cp.add( new JLabel(
            "<html>Launch Windows Task Manager<br>Maximize the size fo this window.<br>"+
            "Watch the memory consumption of this process.<br>"+
            "See that it is in a steady state.<br>"+
            "Change the resolution of the monitor that the application is running on.<br>"+
            "Repeat changing the resolution several times.<br>"+
            "Memory usage of this process appears to jump every time the resolution is changed.<br>"+
            "If repeated enough times Out-of-memory errors will occur with every reapint.<br>"+
            "</html>"), BorderLayout.CENTER );

        frm.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frm.pack();
        frm.setVisible(true);

        while(true)
        {
            frm.repaint();
            try { Thread.sleep(100); } catch (InterruptedException e ) {}
        }
    }
}
---------- END SOURCE ----------

Comments
Duplicate of JDK-8041654
13-05-2015

- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014

- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014