JDK-6204669 : native memory leaks when running under IE windows plugin
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.2_10,6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-12-06
  • Updated: 2010-12-06
  • Resolved: 2005-04-27
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 JDK 6
1.4.2_13Fixed 6 b34Fixed
Related Reports
Duplicate :  
JDK-6348273 - 1.4.2_10: still native memory leaks when running under IE windows plugin
Description
When executing customer's app (which is a plant/factory automation application) in a stress test, a major native memory leak is observed. 

A stress test is using application functionality that causes a new applet to be launched and closed in a repeated fashion. In such configuration a new applet is launched/closed approx. every 10 seconds.

After the application runs for approx. 1 day, the virtual memory used by the iexplore.exe process grows to approx. 500 MB and the page file size grows to approx. 700 MB. At this point, the application typically crashes at some random point. 

The crashes could be in various places, but most of them happen during the malloc() call.

The easiest way to alleviate the customer's issue is to eliminate the native memory leak. 

Minimized test case:

modify Launcher.java below with the location of the JDK 5.0 path (which includes the demo directory): <PATH_TO_JDK5.0>. Copy launcher.java, launcher.html to the demo\applets\ArcTest directory. Compile. 

Run launcher.html below in IE. Press the "launch" button. It will launch the ArcTest Demo in another window. Once loaded, close the ArcTest IE window. Press "launch" button again. Repeat multiple times. 

You can observe a native memory leak in the iexplore.exe process. The test can be automated with a native robotic tool. After running 1 day the iexplore.exe process either hangs or crashes. The native memory usage reaches anout 1.3 Gb.

import java.awt.*;
import java.awt.event.*;
import java.applet.*;
import java.net.*;

Launcher.java :

public class Launcher extends Applet implements ActionListener {

    public void init() {
	Button b = new Button("Launch");
	b.addActionListener(this);
	add(b);
    }

    public void processEvent(AWTEvent e) {
        if (e.getID() == Event.WINDOW_DESTROY) {
            System.exit(0);
        }
    }

    public void actionPerformed(ActionEvent ev) {
        try {
            getAppletContext().showDocument(new URL("file:///<PATH_TO_JDK5.0>\\demo\\applets\\ArcTest\\example1.html"), "_blank");
        } catch (Exception e) {
            System.out.println("Exc : " + e);
        }

    }

}

launcher.html :

<html>
  <head>
      <title>Arc Test Launcher</title>
  </head>
  <body>
      <h1>Arc Test Launcher</h1>
      <hr>
      <applet code=Launcher.class width=400 height=400>
	alt="Your browser understands the &lt;APPLET&gt; tag but isn't running the applet, for some reason."
	Your browser is completely ignoring the &lt;APPLET&gt; tag!
      </applet>
      <hr>
      <a href="Launcher.java">The source</a>.
  </body>
</html>

###@###.### 2004-12-06 20:30:16 GMT
###@###.### 2004-12-09 20:36:47 GMT

The small test case above was run under Numega BoundsChecker (about 50 iterations, system crashes if more iterations are preformed).
The boundschecker memory leak report is attached to this report: iexplore5.bce ). It gives some clues for the problem areas. 

Please note that J2SE was not instrumented with boundschecker, so the information in the report is not 100% complete. J2SE doesn't compile correctly with boundschecker's compiler which is required to instrument the binary 

###@###.### 2004-12-20 00:08:08 GMT

The above mentioned test was modified to remove all the AWT functionality from ArcTest.java. Still significant native leak is observed. This proves that plugin itself does make a significant contribution to the memory leak. The boundschecker report when running in this way is attached also.
###@###.### 2004-12-21 21:47:23 GMT
Comments
SUGGESTED FIX ------- AxControl.cpp ------- *** /tmp/sccs.oQaWuO Thu Jan 13 15:53:46 2005 --- AxControl.cpp Thu Jan 13 15:18:53 2005 *************** *** 475,480 **** --- 479,498 ---- } JNIEnv* env = g_jni->GetJNIEnv(); + // The DispatchWrapper native object is wrapped inside the DispatchClient java + // object. In the case of the jResult of the INOVKESTRUCT is an instance of + // DispatchClient, we need to decrease the ref count of the DispatchWrapper + // object to avoid memory leak. + SmartJClassRef clazz(env, "sun/plugin/com/DispatchClient"); + INVOKESTRUCT *pInvokeStruct = (INVOKESTRUCT *)lParam; + if (pInvokeStruct->jResult != NULL) { + if (env->IsInstanceOf(pInvokeStruct->jResult, clazz)) { + SmartJObjectRef dispClientObj(env, env->NewLocalRef(pInvokeStruct->jResult)); + IDispatchWrapper *pIDispWrapper = (IDispatchWrapper *)dispClientObj.CallIntMethodWithSig("getDispatchWrapper", "()I"); + if (pIDispWrapper != NULL) + pIDispWrapper->Release(); + } + } CJSObject::CleanupInvokeStruct(env, (INVOKESTRUCT*)lParam); return S_OK; ###@###.### 2005-1-13 23:57:08 GMT
13-01-2005
EVALUATION Running the stanalone test case with 1.5.0_02, I've found the following: 1)Instead of creating a new browser window by clicking on the applet's "Launch" button, I've used the browser's File->New->Window to create a new window and then run the ArcTest demo applet in the new window and then close the window. Repeating the above, I've observed similar memory leakage as using the applet's "Launch" button. This implies that the memory leak is likely not due to Java to JavaScript communication. 2) I've also used the jprofiler tool to detect java object leakage and there appears to be none. This confirms that most of the leakage is from the native level. Suspecting the leakage is from the applet shutdown area. ###@###.### 2005-1-06 01:06:46 GMT Using the _ATL_DEBUG_INTERFACES macro with debug libraries, I've tracked down some interface leak as follows: INTERFACE LEAK: RefCount = 1, MaxRefCount = 1, {Allocation = 3} CFactory - {7B4D656B-1C2F-11D6-AB50-00B0D07B8581} INTERFACE LEAK: RefCount = 1, MaxRefCount = 2, {Allocation = 6} CDispatchWrapper - {7B4D656F-1C2F-11D6-AB50-00B0D07B8581} The CFactory leak is fine because that interface was created only once. However, the leakage in CDispatchWrapper is once per new browser window. See suggested fix for the CDispatchWrapper leak. ###@###.### 2005-1-13 23:57:08 GMT
06-01-2005