JDK-6812893 : Java Plugin memory leak when pumping liveconnect with data transfers from applet
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2009-03-04
  • Updated: 2013-01-09
  • Resolved: 2010-06-09
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 6
6-poolResolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Windows XP Professional 2002, Service Pack 2


EXTRA RELEVANT SYSTEM CONFIGURATION :
Internet Explorer 6.0.2900.2180

A DESCRIPTION OF THE PROBLEM :
Transfer of  extensive amounts of data thru a liveconnect connection, either when getting data from javascript or when javascript gets data from an applet, leads eventually to a fast ie slow memory overflow, depending on the amount of data that is sent or received in each cycle. Apparently the system - ie. the internet explorer and/or the JVM - are not consistently releasing the memory after being used (see sample code below).

We have tested two scenarios:

the first one when a js script gets data from its applet using a js timer (see JavascriptToJava.html below) and then iterating this data (array) in  local js function, here process(). This leads to the applet ending abruptedly within a minute timeframe without an exception track.

in the second scenario the data is allocated by the applet and returned to the js thru a thread running on the applet. the js iterates this data again in a local process() - as in the scenario above. In this case the memory slowly grows in JVM until an out of memory exception is thrown.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Open with the IE the file JavascriptToJava.html. Repeat for JavaToJavascript.html. After starting, the IE loads the applet and the tests begin. Please open the windows task manager to monitor the memory usage.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
In both scenarios, after the IE or JVM hace depleted their memory, to release any unused buffers, letting the apllication run indefinetely.
ACTUAL -
See descriptiomn above. the applications terminates unexpectedly.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
in the first scenario there is no error message. in the second scenario a plugin exception (out of memory)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
scenario 1 - JavaScriptTojava.html:
============================
<html>
<head>
<script type="text/javascript">

function process(arr) {
	try {
		var sum = 0;
		for (var i = 0; i < arr.length; i++) {
			sum += arr[i];
		}
		document.getElementById("div1").firstChild.nodeValue = new Date() + ": sum=" + sum;
	} catch (e) {
		alert("Error process: " + e.name + ", " + e.message);
	}
}

function run() {
	var applet = document.getElementById("applet1");
	process(applet.newIntArray(10000));
	setTimeout("run()", 500);
}

</script>
</head>
<body onload="run()">
<h1>Javascript to Java</h1>
<applet id="applet1" code="MemoryLeakApplet.class" mayscript="mayscript">
	<param name="java_arguments" value="-Xms32m -Xmx32m">
</applet>
<div id="div1">init</div>
</body>
</html>

Scenario 2: JavaToJavascript.html
============================
<html>
<head>
<script type="text/javascript">

function process(arr) {
	try {
		var sum = 0;
		for (var i = 0; i < arr.length; i++) {
			sum += arr[i];
		}
		document.getElementById("div1").firstChild.nodeValue = new Date() + ": sum=" + sum;
	} catch (e) {
		alert("Error process: " + e.name + ", " + e.message);
	}
}

function startJava() {
	var applet = document.getElementById("applet1");
	applet.startThread();
}

</script>
</head>
<body onload="startJava()">
<h1>Java to Javascript</h1>
<applet id="applet1" code="MemoryLeakApplet.class" mayscript="mayscript">
	<param name="java_arguments" value="-Xms32m -Xmx32m">
</applet>
<div id="div1">init</div>
</body>
</html>


Java Code
========
import javax.swing.JApplet;

import netscape.javascript.JSObject;

/**
 * JavaToJavascriptApplet.java
 *
 * �� 2009 Fraport AG
 */

/**
 * @author Marijo Basic, Marcelo Krebber, Alexander Sch��nberg
 *
 */
public class MemoryLeakApplet extends JApplet {

	private static final long serialVersionUID = 1L;
	
	private static final int length = 50000;

	public void startThread() {
		Thread thread = new Thread() {
			@Override
			public void run() {
				while (true) {
					JSObject win = (JSObject) JSObject
							.getWindow(MemoryLeakApplet.this);
					win.call("process", new Object[] { newIntArray(length) });
					try {
						Thread.sleep(500);
					} catch (InterruptedException e) {
						e.printStackTrace();
					}
				}
			}
		};
		thread.start();
	}

	public int[] newIntArray(int length) {
		return new int[length];
	}

}


---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
no bypassing known to us.

Comments
EVALUATION This issue was identified to be a duplicate of CR 6857340. It was verified that 6u20 b03 which contains the fix for CR 6857340 solves the memory leak problem. At the same time it still demonstrates the named pipe read error under Win XP / IE 7. It looks like a different issue not related to the memory leak. It is tracked as CR 6959808.
09-06-2010

EVALUATION For the javascript to java testcase, the client jvm exited unexpected is due to an error during reading (ReadFile()) from the named pipe on the browser side. The ReadFile() returns 0 indicating an error and the error code is 109 - the pipe has been ended. Due to the error, an IOException wil be thrown and the pipe will be shutdown. With the pipe shutdown, there's no hearbeat detected on the client jvm and it exits.
03-10-2009