JDK-6494370 : JRE 6 RC hangs in IE when console and debug options are selected
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6,6u1
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-11-16
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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
6u2Fixed 7 b13Fixed
Related Reports
Relates :  
JDK-6418035 - Applets freeze in 5u7 on XP Japanese
Relates :  
JDK-6541135 - 6u2 Regression: Java beans embedded inside VB using ActiveX feature throwing UnsatisfiedLinkError
Description
FULL PRODUCT VERSION :
java version "1.6.0-rc"
Java(TM) SE Runtime Environment (build 1.6.0-rc-b104)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b104, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Windows XP Professional Version 2002 Service Pack 2
Windows 2000 5.00.2195 Service Pack 4

A DESCRIPTION OF THE PROBLEM :
Using the JRE 6 Release Candidate with all three 'Debugging' options (Enable tracing, Enable logging and Show applet lifecycle exceptions) and 'Show Console' selected in the Java Control Panel, running a simple applet sometimes results in a browser hang in Internet Explorer. This appears to be a timing issue when the VM is starting up, and results in both the java console and the web page freezing and being labelled 'Not Responding' in the Task Manager.

This was observed using Internet Explorer version 7.0.5730.11IS on Windows XP, and Internet Explorer version 6.0.2800.1106IS on Windows 2000. It occured in about ten percent of cases where the browser was opened on a page containing an applet, such as:

http://www.objectplanet.com/newsticker/changes.html

A test case is included that demonstrates the problem using a very simple applet and html page.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. On Windows XP, open the Java Control Panel and open the Advanced tab.
2. Under Settings -> Debugging, select the 'Enable tracing', 'Enable logging' and 'Show applet lifecycle exception' checkboxes.
3. Under Settings->Java console, select the 'Show console' radio button.

4. Create a file called SimpleApplet.html containing the following text:

<HTML>
<HEAD>
<TITLE> New Document </TITLE>
</HEAD>
<BODY>
Simple Applet
<applet code="SimpleApplet.class"
width="200" height="200" align="center">
</applet>
</BODY>
</HTML>


5. Create a SimpleApplet class using the following code:

import java.applet.Applet;

public class SimpleApplet extends Applet
{
	public void start()
	{
		super.start();
		System.out.println("applet started....");
	}
}

6. Compile SimpleApplet.java and place the class file in the same directory as SimpleApplet.html.

7. Open 'SimpleApplet.html' using IE.

8. IE 7 will initially block the applet saying 'To help protect your security IE has restricted this webpage....Click here for options.' Click the banner and select 'Allow blocked content'

9. IE 7 displays an 'Are you sure you want to let this file run active content?' prompt. Click 'yes'.


Alternatively, open IE and browse to the ObjectPlanet newsticker applet page:

http://www.objectplanet.com/newsticker/changes.html

ensuring that the newsticker page is the first page containing an applet encountered, so it has to start the VM.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The page should load, the java console should start up and display debug output like this:

liveconnect: Invoking JS method: document
liveconnect: Invoking JS method: URL
basic: Referencing classloader: sun.plugin.ClassLoaderInfo@1e51060, refcount=1
basic: Added progress listener: sun.plugin.util.GrayBoxPainter@124bbbf
basic: Loading applet ...
basic: Initializing applet ...
basic: Starting applet ...
basic: completed perf rollup
applet started....

including the 'applet started' output from the SimpleApplet.
ACTUAL -
In about ten percent of case of cases the page and console freeeze and can only be closed using the Task Manager. No output is visible in the console, and two Java icons are visible in the bottom right of the TaskBar.

REPRODUCIBILITY :
This bug can be reproduced often.

---------- BEGIN SOURCE ----------
import java.applet.Applet;

public class SimpleApplet extends Applet
{
	public void start()
	{
		super.start();
		System.out.println("applet started....");
	}
}
---------- END SOURCE ----------
Comments
EVALUATION The workaround put back for JDK 6 update 2 has been forward ported to the 7 release train and is expected to be integrated in roughly build 12.
23-03-2007
EVALUATION The fix for the Yokogawa problem, which is more general than this specific bug fix and subsumes it, is targeted at update 3 in the Java SE 6 update release train.
28-02-2007
EVALUATION After further discussion with ###@###.### there is another larger-scale fix for a problem reported by Yokogawa in progress. That fix subsumes this one by doing the operations in question completely asynchronously. We are going to defer this fix in favor of the other one. At the point where that fix goes back this bug will be closed as a duplicate.
06-02-2007
EVALUATION This fix has been verified by the customer against the Java 6 release train as well as with one of the Yokogawa test cases (no apparent bad side effects) and with a couple of other applets. It seems to be robust enough to be put back into the product at this point.
24-01-2007
EVALUATION The problem appears to be a three-way deadlock between the browser's main thread, one of the AWT event dispatch threads, and the AWT-Windows toolkit thread. There are two scenarios involving different work being done on the browser's main thread, but the basic idea is that the main thread is doing some AWT-related work like constructing the embedded frame or calling setBean() to put the applet in it. This results in a native method call in which the AWT native code grabs a critical section object and tries to execute a callback on the AWT-Windows thread. In the meantime, the background AWT event dispatch thread (EDT) is performing a focus change, presumably to transfer the focus to the Java Console window. This causes the EDT to enter the same critical section and to perform a callback on the AWT toolkit thread. The EDT is the actual owner of the critical section at the time of the deadlock; the browser main thread is waiting to enter the critical section. The toolkit thread is executing the callback on behalf of the EDT, which is performing a SendMessage call of WM_KILLFOCUS to the current focus owner, which is the browser's window. This synchronous message send needs to be handled by the browser's main thread in order to complete, but because the browser's main thread is blocked on the critical section owned by the EDT, it will never pump the WM_KILLFOCUS message and the process deadlocks. The most targeted solution to this problem is to do the work currently being done by the browser's main thread on a background thread (in this case, the main ThreadGroup's EDT will suffice) and to pump certain messages while waiting for that work to complete, in order to not introduce any additional asynchronous behavior in the plug-in. It turns out that if we pump all Windows messages while waiting for the work to complete, we make the plugin reentrant in certain ways that are not handled by either the plugin or the ATL, so we only pump WM_KILLFOCUS messages to break this specific deadlock.
19-01-2007