JDK-6613949 : run Yokogawa reliability test with new plug-in bundle caused big handle leaks
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u5
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-10-08
  • Updated: 2010-08-07
  • Resolved: 2007-10-31
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
6u10Resolved
Related Reports
Duplicate :  
JDK-6622332 - Initial integration of new Java Plug-In
Relates :  
JDK-6630062 - run Yoko* reliability test with new plug-in doubles the handles used compared with old plug-in
Relates :  
JDK-6592751 - EmbeddedFrame disposal is fragile and breaks clean AppContext termination
Description
* Tested build: http://analemma.sfbay.sun.com/net/jano1/export1/deployment/kbr/plugin2-testing/jre-6u5-plugin2-windows-i586-p-03_oct_2007.exe
and * Tested build: http://analemma.sfbay.sun.com/net/jano1/export1/deployment/kbr/plugin2-testing/jre-6u5-plugin2-windows-i586-p-05_oct_2007.exe

Platform: WinXP pro, English
Test run: yokogawa test YokogawaTC4_001

handle count grow from 672 to 112877, 
private bytes grow from 37,519,360 to 347,226,112

The reports are at
http://sqeweb.sfbay/i18n/yokogawa/6u5-new-plugin/Standalone_deployment_plugin_2007_10_06_11_36_01/

http://sqeweb/i18n/yokogawa/6u5-new-plugin/Standalone_deployment_plugin_2007_10_06_11_36_01/i18n-sqe.Windows_XP.x86/YokogawaTC4_001/iexplore.csv
demonstrate the counts, the test failed with browser hang.

The large handle leaks is also observed in promotion build 6u5 b03, in just 8 minutes run, handle count grew from 815 to 1337.
Comments
EVALUATION This bug is being marked as a duplicate of 6622332 for bookkeeping purposes and does not need to be re-verified independently. In the case of a regression please file a new bug.
31-10-2007
EVALUATION There was one call site in the native COM code in the new plug-in for IE where we were leaving a dangling reference to a browser-side COM object (the interface to the JavaScript scripting engine, in the form of the IHTMLWindow2). Changed this site to use a smart pointer. The Java-side code performs a manual AddRef/Release of this COM object, so doing so is safe and we never refer to this object after decrementing its reference count potentially to 0. This addresses the major handle leak. However, it is apparent that with IE 7 the handle count and memory usage of iexplore.exe still increase over time. This appears to be a bug in IE. Manual experimentation with repeatedly loading a web page that does not use Java, in the same fashion as the Yokogawa TC4_001 scenario, shows the same kind of handle leak as seen with this test case. Additionally, the old plug-in at least as far back as 6u2 exhibits the same leak, so this does not appear to be a bug in the new plug-in. ###@###.### and ###@###.### have encountered this leak before. I have not had a chance to try running this fix with IE 6. Also increased the cooperative stop timeout from 500 ms to 1000 ms to avoid tearing down applets "hard" too often. This adjustment reduces the number of times a new JVM is launched and the old one shut down during repeated page reloads, since tearing down an applet "hard" provokes AWT bug 6592751, which results in the JVM being marked tainted.
17-10-2007
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u5/6613949.1
17-10-2007