JDK-6647070 : JSObject reference counting problem
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-01-04
  • Updated: 2010-09-08
  • Resolved: 2008-01-29
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
6u10 b11Fixed
Related Reports
Relates :  
JDK-6644253 - Plugin2: Issues with Null type handling while Java > JS communication
Relates :  
JDK-6644857 - New Plug-In does not call preJVMStart()
Relates :  
JDK-6647430 - Java Kernel error message in development builds causing plugin crashes with Firefox
Relates :  
JDK-6613373 - Plugin2: Applet fails to load in case invalid run time params are supplied
Description
User jasuha1 on the java.net forums has reported a problem with the scoping of JSObjects. The attached test case loads the same web page three times in separate iframes. Each applet instance fetches the JSObject associated with the surrounding window. One of the iframes is then destroyed. The JSObjects associated with the other applet instances have then been invalidated.

This is a regression compared to the old Java Plug-In.

There is clearly a problem in the distributed reference counting scheme used by the shared LiveConnect code.

Links to associated forum threads:
http://forums.java.net/jive/thread.jspa?threadID=34807&tstart=0
http://forums.java.net/jive/thread.jspa?threadID=34805&tstart=0
The attached test case also crashes the Firefox 3 port of the new Java Plug-In if it is the first applet launched in the browser session. This must also be investigated.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6647070.0 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6647070/
05-01-2008
EVALUATION This test case from user jasuha1 on the java.net forums uncovered several unrelated problems in addition to the underlying bug. The first and most obvious of these was a crash in Firefox 3 during loading of the test case. This was a regression caused by the introduction of the call to the Java Kernel's preJVMStart() in 6644857. In a development build with no rt.jar, this call will pop up a Windows message box indicating that rt.jar could not be found. While the dialog box is up, messages are being pumped, and it turns out that this causes the browser main thread in Firefox to continue initializing other elements on the web page. Halfway through the initialization sequence of the first applet, the second one starts initializing. This causes the Java Plug-In's code to be called in an unexpectedly reentrant fashion and initialization to be performed out of order. Partial workarounds for this problem were added to the InitializeJVM() call in JavaVM.c and some of the plugin's code in MozPluginExports.cpp. Note that these changes are only a partial workaround and that the best workaround for this problem lies in the Java Kernel. 6647430 has been filed to further track this issue. The second problem was a regression introduced with the fix for Java/JavaScript null value handling in 6644253. Java-to-JavaScript calls returning void were causing a NullPointerException to be thrown during unmarshaling of the return result from the JavaScript engine. Added a needed null check to the client-side LiveConnectSupport class and proactively added a null check to the ArgumentHelper class which is not currently called. The third problem was a regression in the browser-side heartbeat code (added in 6609036) which was introduced with the fix for 6613373 related to handling of invalid command-line arguments. The initial ping in PluginMain was being sent back to the browser too early, and in some cold start scenarios when the browser sent the SetJVMIDMessage to the attached JVM, the call to Applet2Environment.initialize() took so long that the browser would kill the attached JVM instance. Changed PluginMain to send the message back to the browser later, after all of the one-time initialization of the attached JVM is done. After all of these other fixes, the underlying bug was remarkably small. The browser-side LiveConnectSupport class keeps track of which JavaScript objects have been exposed to the currently running applets. The comments in the code indicate that these objects are tracked on a per-applet basis. Unfortunately, the HashSet in the class tracking these objects was a static variable instead of an instance member. This meant that if any applet was destroyed, all existing JSObjects for any running applets, even in other browser windows, would be invalidated, breaking Java->JavaScript communication. This is a staggering bug that it is astounding was not found by our testing before now. A big thanks to the submitter for the excellent test case. This only fixes the problem of incorrect JSObject invalidation. There is another problem in the submitter's original test case only with the new plug-in on Firefox 3 where JavaScript calls initiated from an NPRuntime plug-in can not cross the frame boundary. This is a browser bug and has been filed on http://bugzilla.mozilla.org as 410853: https://bugzilla.mozilla.org/show_bug.cgi?id=410853 . See the test case attached to that bug for a user-level workaround; unfortunately no workaround is possible in the Java Plug-In.
05-01-2008