JDK-6926432 : massive outputs to a hidden Java Console fill the heap until exhaustion resulting in browser hang
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u18-rev,6u31
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: windows,windows_xp
  • CPU: generic,x86
  • Submitted: 2010-02-15
  • Updated: 2016-10-20
  • Resolved: 2016-10-20
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 7
7Fixed
Related Reports
Duplicate :  
Relates :  
Description
A mass of outputs to a hidden Java Console will fill the heap until exhaustion resulting in the browser and applet to be unresponsive.

Steps to reproduce :
- Start the Java Control Panel and choose to "Hide" or "Do not start" the Java Console.
- Run the applet provided below in your prefered browser .
- Start jvisualvm to monitor the java-plugin process.

You will see the java heap filling until exhaustion. Some GC tentatives will be useless. The Applet and browser will become unresponsive.

Reproduced with 1.6u18 on Win XP/IE8 with both old and new plugin and Solaris10/Firefox.

% cat TestApplet.java
import javax.swing.*;
import java.awt.*;

public class TestApplet extends java.applet.Applet {

  public void init (){
        JPanel panel = new JPanel();
         Label a = new Label("JConsole Test");
        panel.add(a);
        add(panel);

        Thread testThread = new Thread(){
            public void run()
            {
                int i = 0;
                while( true )
                {
                    System.out.println("************************");
                    for( int j = 0 ; j < 5000 ; j++)
                        System.out.println("Console Test: "+ i + "-" + j);
                    try{
                        sleep(500);
                    }catch ( Exception ex)
                    {
                        ex.printStackTrace();
                    }
                    i++;
                }
            }
        };
        testThread.start();
  }
}
I���m sorry. There is a delay while I am working on some higher priority escalations. I expect to be able to get back to this next week.

Comments
Issue seems to be fixed "enough" in JDK 7. For JDK 6, we will not address this as the deploy stack for JDK 6 is already near the end of its service life.
20-10-2016

EVALUATION I'd prepared a debug binary where I'd disabled buffering of the Java console output, but it didn't eliminate the memory leak. Here are the maximum counter values the test case was able to proceed to: 6u20 b05 with console: 36-424 6u20 b05 without console: 37-4127 6u20-based FVB with console: 33-2504 6u20-based FVB without console: 39-324 Then execution of the test case dramatically slowed down and effectively stopped. In another experiment I verified that the memory leak depends on the value of "Enable tracing" option of the Java Control Panel. When it's disabled ("Enable logging" = true, "Do not start console"), the debug binary shows no memory leak. According to the log file, which was continuously updated during the test case execution, the counter reached 410-XXXX and higher values, and the execution speed was very high. Furthermore, if I then open the console using UI, it starts tracing the output, and the memory usage is still stable. According to the code, it means that the largest part of the memory leak is caused by FileTraceListener operation, and ConsoleTraceListener is not the culprit here.
17-06-2010

WORK AROUND Select to "Show the Console" in the Java Control Panel *** (#1 of 1): [ UNSAVED ] ###@###.###
15-02-2010