United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6613949 run Yokogawa reliability test with new plug-in bundle caused big handle leaks
6613949 : run Yokogawa reliability test with new plug-in bundle caused big handle leaks

Details
Type:
Bug
Submit Date:
2007-10-08
Status:
Closed
Updated Date:
2010-08-07
Project Name:
JDK
Resolved Date:
2007-10-31
Component:
deploy
OS:
windows_xp
Sub-Component:
plugin
CPU:
x86
Priority:
P2
Resolution:
Duplicate
Affected Versions:
6u5
Fixed Versions:
6u10

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

Sub Tasks

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.
2007-10-31 
SUGGESTED FIX

http://sa.sfbay.sun.com/projects/deployment_data/6u5/6613949.1
2007-10-17 
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.
2007-10-17


Hardware and Software, Engineered to Work Together