JDK-6760921 : Browser hang while reloading LiveConnect conformance tests on Unix platforms
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10,6u11
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2008-10-17
  • Updated: 2010-09-08
  • Resolved: 2008-10-18
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
6u11 b02Fixed
Related Reports
Duplicate :  
JDK-6764341 - Program hangs when calling JS in Firefox 3 on Linux
Relates :  
JDK-6630062 - run Yoko* reliability test with new plug-in doubles the handles used compared with old plug-in
Description
While stress-testing the LiveConnect conformance tests (http://jdk6.dev.java.net/nonav/plugin2/liveconnect/LiveConnectTests/) it was discovered that reloading the web page after the tests have completed causes the Firefox web browser to hang 100% of the time on Unix platforms.
Comments
EVALUATION While running the LiveConnect conformance tests on Firefox 3 on Unix platforms, it was discovered that reloading the page would hang the browser. The root cause of the hang is related to how asynchronous events are processed on the browser's main thread, and the definition of the browser main thread itself. Essentially, the Java Plug-In assumes that the java.lang.Thread associated with the browser's main thread is stable. Early in the 6u10 release a Yokogawa resource leak was fixed (6630062) and during that fix it was discovered that detaching the browser's main thread introduced then-unknown resource leaks on Windows. Now it is understood that in the Firefox plug-in, the resource leak was a Java-level one, caused by the java.lang.Thread associated with the browser's main thread changing at unexpected times. The correct fix under the circumstances is to not detach the browser's main thread from the JVM upon destruction of the Java Plug-In instance. This has the potential of introducing resource leaks in NPAPI browsers that have a main thread per browser window; it is not known whether any exist at the present time, but Firefox definitely only has one main thread for all of its windows. Comments have been added to the code describing this potential situation.
18-10-2008
SUGGESTED FIX webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u11/6760921.0 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_11/6760921/
18-10-2008
EVALUATION The root cause of the problem is very subtle, relating to the threading model of the web browser and how the Java Plug-In schedules work to be done on the browser's main thread, but the fix is extremely simple: do not detach the browser's main thread from the JVM upon Java Plug-In shutdown. The detaching and reattaching causes the identity of the java.lang.Thread corresponding to the browser's main thread to change over time, breaking Java-level logic in the new Java Plug-In.
17-10-2008