JDK-6550906 : IE/JVM crashes when modifying browser DOM from applet
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-04-26
  • Updated: 2010-12-07
  • Resolved: 2007-06-30
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 JDK 7
6u4 b01Fixed 7Fixed
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310

FULL OS VERSION :
ver: Windows XP Build 2600 Service Pack 2

EXTRA RELEVANT SYSTEM CONFIGURATION :
INTERNET EXPLORER 6.0.2900.2180.xpsp_sp2.qfe.070227-0300
OS: Windows XP Build 2600 Service Pack 2
CPU:total 2 family 6, cmov, cx8, fxsr, mmx, sse, sse2
Memory: 4k page, physical 2096300k(938668k free), swap 4037840k(3032392k free)
vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310


A DESCRIPTION OF THE PROBLEM :
IE/JVM gets destabilized when a Java applet modifies browser DOM. The browser crashes after the applet code is run and page reload is invoked. Crashing has been however observed also randomly without page reloads required (less frequently).

I'm providing the source code lower; NetBeans project, test HTML page and the applet jar can be found here:
http://wiki.netbeans.org/wiki/attach/JK_ScratchPad/CrashIEApplet.zip
http://wiki.netbeans.org/wiki/attach/JK_ScratchPad/index.html
http://wiki.netbeans.org/wiki/attach/JK_ScratchPad/CrashIEApplet.jar

As for the source code - crash occurs if the code is executed in the Applet's start method, in a public method invoked from the browser upon a HTML button click and even if the code is executed in a separate Java thread.

THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Did not try

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Did not try

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the applet (you may want to use the attached index.html).
Hit the 'say hello' button. Refresh the page. Try a couple times. IE crashes.

EXPECTED VERSUS ACTUAL BEHAVIOR :
IE should not crash.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
See Attachment (hs_err_pid.log)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package test;

import netscape.javascript.JSObject;

/**
 *
 * @author Jiri Kopsa
 */
public class CrashIEApplet extends javax.swing.JApplet {
    
    public void printHello() {
        
        new Thread(new Runnable(){
            public void run(){
                for (int i=0; i < 20; i++) {
                    JSObject win = getWindow();
                    JSObject document = (JSObject) win.getMember("document");
                    JSObject jso = (JSObject) document.call("createElement",new String[]{"div"});
                    jso.setMember("innerHTML", "Hello <b>world</b>!");
                    JSObject body = (JSObject) document.getMember("body");
                    body.call("appendChild", new Object[]{jso});
                }
            }
        }).start();
    }
    
    public JSObject getWindow(){
        return (JSObject) JSObject.getWindow(this);
    }
    
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
None known.

Comments
EVALUATION Thanks to ###@###.###'s suggestion, a better and more correct fix is not to use smart pointer when creating an instance of IDispatchWrapper in ObjectTypeConverter. The problem with using a smart pointer is that the pointer will be valid only within the scope in which it was declared. So when it is being released in CAxControl::OnJSFinalize, we're ending up releasing an interface which is no longer valid and thus causing the crash.
23-05-2007

SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u3/6550906.1/
23-05-2007

EVALUATION The browser crash is due to our CAxControl is releasing the IDispatchWrapper twice. A fix is to check the bHandled parameter. Only releasing IDispatchWrapper if bHandled is set to FALSE.
23-05-2007

EVALUATION Definitely reproducible, and crashing in the Plug-In's LiveConnect implementation on IE. It isn't clear yet whether this is a problem in the common DOM code or in the lower-level LiveConnect support, but even if the common DOM code is buggy, it shouldn't be possible to crash the JVM just by manipulating JSObjects. Will continue to investigate. An hs_err log file is attached showing the stack trace at the point of the crash (Windows XP SP2, IE 7, 6.0u2 internal build).
22-05-2007