United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6550906 IE/JVM crashes when modifying browser DOM from applet
JDK-6550906 : IE/JVM crashes when modifying browser DOM from applet

Details
Type:
Bug
Submit Date:
2007-04-26
Status:
Resolved
Updated Date:
2010-12-07
Project Name:
JDK
Resolved Date:
2007-06-30
Component:
deploy
OS:
windows_xp
Sub-Component:
plugin
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:
6u4 (b01)

Related Reports
Backport:
Relates:

Sub Tasks

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

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).
                                     
2007-05-22
SUGGESTED FIX

http://sa.sfbay.sun.com/projects/deployment_data/6u3/6550906.1/
                                     
2007-05-23
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.
                                     
2007-05-23
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.
                                     
2007-05-23



Hardware and Software, Engineered to Work Together