Bug ID: JDK-6418035 Applets freeze in 5u7 on XP Japanese

JDK-6418035 : Applets freeze in 5u7 on XP Japanese

Type: Bug
Component: deploy
Sub-Component: plugin
Affected Version: 5.0u7,5.0u8,6

Priority: P2
Status: Closed
Resolution: Cannot Reproduce
OS: windows_xp
CPU: x86

Submitted: 2006-04-26
Updated: 2011-01-20
Resolved: 2010-11-17

Versions (Unresolved/Resolved/Fixed)

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.

Other	JDK 6	JDK 7
5.0u12Fixed	6u6Resolved	7Resolved

Related Reports

Duplicate :	JDK-6440220 - IE/Plugin hang reloading ArcTest during WComponentPeer._requestFocus()
Relates :	JDK-6576321 - Browser hang by a deadlock with open and close applet repeatedly
Relates :	JDK-2147416 - JRE 6 RC hangs in IE when console and debug options are selected
Relates :	JDK-6226054 - Dialogue doesn't appear when a new window is invoked at the same time in 1.4.2_06/5.0fcs
Relates :	JDK-6494370 - JRE 6 RC hangs in IE when console and debug options are selected

Description

Test Configuration:  
-------------------
  - WindowsXP (only Japanese, SP1)  
   (contact ###@###.### for access to this Virtual PC test JP env.)
  - IE 6
  - jre 5u7-b02


Problem: 
-------
Applet windows were frozen after repeatly trying to open and close "New Window" 
and "Call Dialog" buttons (for sometime between 1 minute to 15 minutes). 
The problem does not occur on 1.4.2


Steps to reproduce:
------------------

1) Using IE loads the attached <SampleApplet.html>
2) The sleeping time can be set in the Text Field from 250 - 350
   (this is the delay time between actions)
3) Repeatly click to open and close "New Window" button / "Call Dialog" button
(for sometime between 1 minute to 15 minutes, and 1 second between each click)

The applet windows eventually freeze. Attached is the screeshot <vpc_tc05_hang.bmp> at the time the applet windows hang (VPC Japanese XP was displayed on the top of English XP)
ADPlus stack track attached
Here's the java stack trace at the hang point:

Thread 19: (state = BLOCKED, current Java SP = 0x08df7f70
)
- java.lang.Object.wait(long), pc=0x046a826f, methodOop=0x2b3d15f0 (Interpreted frame)
- java.lang.Object.wait() @bci=2, pc=0x046a2923, methodOop=0x2b3d1668 (Interpreted frame)
- com.sun.deploy.util.DeployAWTUtil.invokeAndWait(java.awt.Component, java.lang.Runnable) @bci=52, pc=0x046a2923, methodOop=0x26d5f030 (Interpreted frame)
- sun.plugin.viewer.frame.IExplorerEmbeddedFrame.setBean(java.lang.Object) @bci=10, pc=0x046a2923, methodOop=0x26cfb410 (Interpreted frame)
- sun.plugin.viewer.IExplorerPluginObject.createFrame(int) @bci=44, pc=0x046a2923, methodOop=0x26d51d70 (Interpreted frame)


Thread 18: (state = IN_NATIVE, current Java SP = 0x080ff450
)
- sun.awt.windows.WDialogPeer.showModal(), pc=0x046a826f, methodOop=0x26db1908 (Interpreted frame)
- sun.awt.windows.WDialogPeer.show() @bci=30, pc=0x046a2923, methodOop=0x26db1ad0 (Interpreted frame)
- java.awt.Dialog.conditionalShow() @bci=49, pc=0x046a2c29, methodOop=0x2b680698 (Interpreted frame)
- java.awt.Dialog.show() @bci=53, pc=0x046a2a7b, methodOop=0x2b6806d0 (Interpreted frame)
- javax.swing.JOptionPane.showOptionDialog(java.awt.Component, java.lang.Object, java.lang.String, int, int, javax.swing.Icon, java.lang.Object[], java.lang.Object) @bci=70, pc=0x046a2923, methodOop=0x26d9f9f0 (Interpreted frame)
- SampleApplet.jButton1_actionPerformed(java.awt.event.ActionEvent) @bci=27, line=82, pc=0x046a29cf, methodOop=0x26d79408 (Interpreted frame)
- SampleApplet$1.actionPerformed(java.awt.event.ActionEvent) @bci=5, line=31, pc=0x046a2923, methodOop=0x26d8adf8 (Interpreted frame)
- javax.swing.AbstractButton.fireActionPerformed(java.awt.event.ActionEvent) @bci=84, pc=0x046a2c29, methodOop=0x2b6596e8 (Interpreted frame)
- javax.swing.AbstractButton$Handler.actionPerformed(java.awt.event.ActionEvent) @bci=5, pc=0x046a2923, methodOop=0x2b6b98c0 (Interpreted frame)
- javax.swing.DefaultButtonModel.fireActionPerformed(java.awt.event.ActionEvent) @bci=35, pc=0x046a2c29, methodOop=0x2b6b8bf0 (Interpreted frame)
- javax.swing.DefaultButtonModel.setPressed(boolean) @bci=117, pc=0x046a2923, methodOop=0x2b6b8988 (Interpreted frame)
- javax.swing.plaf.basic.BasicButtonListener.mouseReleased(java.awt.event.MouseEvent) @bci=35, pc=0x046a2c29, methodOop=0x2b6bea60 (Interpreted frame)
- java.awt.Component.processMouseEvent(java.awt.event.MouseEvent) @bci=64, pc=0x046a2c29, methodOop=0x2b480d68 (Interpreted frame)
- javax.swing.JComponent.processMouseEvent(java.awt.event.MouseEvent) @bci=23, pc=0x046a2923, methodOop=0x2b579f70 (Interpreted frame)
- java.awt.Component.processEvent(java.awt.AWTEvent) @bci=81, pc=0x046a2923, methodOop=0x2b480c88 (Interpreted frame)
- java.awt.Container.processEvent(java.awt.AWTEvent) @bci=18, pc=0x046a2923, methodOop=0x2b4874c0 (Interpreted frame)
- java.awt.Component.dispatchEventImpl(java.awt.AWTEvent) @bci=477, pc=0x046a2923, methodOop=0x2b4802b0 (Interpreted frame)
- java.awt.Container.dispatchEventImpl(java.awt.AWTEvent) @bci=42, pc=0x046a2923, methodOop=0x2b487530 (Interpreted frame)
- java.awt.Component.dispatchEvent(java.awt.AWTEvent) @bci=2, pc=0x046a2923, methodOop=0x2b480278 (Interpreted frame)
- java.awt.LightweightDispatcher.retargetMouseEvent(java.awt.Component, int, java.awt.event.MouseEvent) @bci=304, pc=0x046a2923, methodOop=0x2b4ae960 (Interpreted frame)
- java.awt.LightweightDispatcher.processMouseEvent(java.awt.event.MouseEvent) @bci=139, pc=0x046a2923, methodOop=0x2b4ae810 (Interpreted frame)
- java.awt.LightweightDispatcher.dispatchEvent(java.awt.AWTEvent) @bci=50, pc=0x046a2a7b, methodOop=0x2b4ae7a0 (Interpreted frame)
- java.awt.Container.dispatchEventImpl(java.awt.AWTEvent) @bci=12, pc=0x046a2a7b, methodOop=0x2b487530 (Interpreted frame)
- java.awt.Component.dispatchEvent(java.awt.AWTEvent) @bci=2, pc=0x046a2923, methodOop=0x2b480278 (Interpreted frame)
- java.awt.EventQueue.dispatchEvent(java.awt.AWTEvent) @bci=46, pc=0x046a2923, methodOop=0x2b52c788 (Interpreted frame)
- java.awt.EventDispatchThread.pumpOneEventForHierarchy(int, java.awt.Component) @bci=233, pc=0x046a2923, methodOop=0x2b54a268 (Interpreted frame)
- java.awt.EventDispatchThread.pumpEventsForHierarchy(int, java.awt.Conditional, java.awt.Component) @bci=26, pc=0x046a2a7b, methodOop=0x2b54a1f8 (Interpreted frame)
- java.awt.EventDispatchThread.pumpEvents(int, java.awt.Conditional) @bci=4, pc=0x046a2923, methodOop=0x2b54a1c0 (Interpreted frame)
- java.awt.EventDispatchThread.pumpEvents(java.awt.Conditional) @bci=3, pc=0x046a2923, methodOop=0x2b54a150 (Interpreted frame)
- java.awt.EventDispatchThread.run() @bci=9, pc=0x046a2923, methodOop=0x2b54a118 (Interpreted frame)


Thread 17: (state = BLOCKED, current Java SP = 0x07dffa74
)
- java.lang.Object.wait(long), pc=0x046a826f, methodOop=0x2b3d15f0 (Interpreted frame)
- javax.swing.TimerQueue.run() @bci=14, pc=0x046a2923, methodOop=0x2b6ad570 (Interpreted frame)
- java.lang.Thread.run() @bci=11, pc=0x046a2c29, methodOop=0x2b3e1ae0 (Interpreted frame)


Thread 16: (state = BLOCKED, current Java SP = 0x07effb18
)
- java.lang.Object.wait(long), pc=0x046a826f, methodOop=0x2b3d15f0 (Interpreted frame)
- java.lang.Object.wait() @bci=2, pc=0x046a2923, methodOop=0x2b3d1668 (Interpreted frame)
- sun.applet.AppletPanel.getNextEvent() @bci=18, pc=0x046a2923, methodOop=0x26c209e8 (Interpreted frame)
- sun.applet.AppletPanel.run() @bci=31, pc=0x046a29fa, methodOop=0x26c20f08 (Interpreted frame)
- java.lang.Thread.run() @bci=11, pc=0x046a2c29, methodOop=0x2b3e1ae0 (Interpreted frame)


Thread 15: (state = BLOCKED, current Java SP = 0x077ef7ac
)
- java.awt.Container.addImpl(java.awt.Component, java.lang.Object, int) @bci=8, pc=0x046ae417, methodOop=0x2b486b58 (Interpreted frame)
- java.awt.Container.add(java.awt.Component) @bci=4, pc=0x046a2923, methodOop=0x2b4867a0 (Interpreted frame)
- sun.plugin.viewer.frame.IExplorerEmbeddedFrame.setComponent(java.awt.Component) @bci=11, pc=0x046a29fa, methodOop=0x26cfb368 (Interpreted frame)
- sun.plugin.viewer.frame.IExplorerEmbeddedFrame.access$100(sun.plugin.viewer.frame.IExplorerEmbeddedFrame, java.awt.Component) @bci=2, pc=0x046a2923, methodOop=0x26cfbce8 (Interpreted frame)
- sun.plugin.viewer.frame.IExplorerEmbeddedFrame$1.run() @bci=65, pc=0x046a2923, methodOop=0x26d5e970 (Interpreted frame)
- java.awt.event.InvocationEvent.dispatch() @bci=11, pc=0x046a2c29, methodOop=0x2b548e10 (Interpreted frame)
- java.awt.EventQueue.dispatchEvent(java.awt.AWTEvent) @bci=26, pc=0x046a2c29, methodOop=0x2b52c788 (Interpreted frame)
- java.awt.EventDispatchThread.pumpOneEventForHierarchy(int, java.awt.Component) @bci=233, pc=0x046a2923, methodOop=0x2b54a268 (Interpreted frame)
- java.awt.EventDispatchThread.pumpEventsForHierarchy(int, java.awt.Conditional, java.awt.Component) @bci=26, pc=0x046a2a7b, methodOop=0x2b54a1f8 (Interpreted frame)
- java.awt.EventDispatchThread.pumpEvents(int, java.awt.Conditional) @bci=4, pc=0x046a2923, methodOop=0x2b54a1c0 (Interpreted frame)
- java.awt.EventDispatchThread.pumpEvents(java.awt.Conditional) @bci=3, pc=0x046a2923, methodOop=0x2b54a150 (Interpreted frame)
- java.awt.EventDispatchThread.run() @bci=9, pc=0x046a2923, methodOop=0x2b54a118 (Interpreted frame)


Thread 14: (state = BLOCKED, current Java SP = 0x076ef9c4
)
- java.lang.Object.wait(long), pc=0x046a826f, methodOop=0x2b3d15f0 (Interpreted frame)
- java.lang.Object.wait() @bci=2, pc=0x046a2923, methodOop=0x2b3d1668 (Interpreted frame)
- sun.awt.AWTAutoShutdown.run() @bci=32, pc=0x046a2923, methodOop=0x2b4bf508 (Interpreted frame)
- java.lang.Thread.run() @bci=11, pc=0x046a2c29, methodOop=0x2b3e1ae0 (Interpreted frame)


Thread 12: (state = BLOCKED, current Java SP = 0x074efb4c
)
- java.lang.Object.wait(long), pc=0x046a826f, methodOop=0x2b3d15f0 (Interpreted frame)
- java.lang.Object.wait() @bci=2, pc=0x046a2923, methodOop=0x2b3d1668 (Interpreted frame)
- com.sun.deploy.util.Trace$TraceMsgQueueChecker.run() @bci=30, pc=0x046a2923, methodOop=0x26c50fb8 (Interpreted frame)
- java.lang.Thread.run() @bci=11, pc=0x046a2c29, methodOop=0x2b3e1ae0 (Interpreted frame)


Thread 11: (state = IN_NATIVE, current Java SP = 0x072dfc08
)
- sun.awt.windows.WToolkit.eventLoop(), pc=0x046a826f, methodOop=0x2b4bce80 (Interpreted frame)
- sun.awt.windows.WToolkit.run() @bci=69, pc=0x046a2923, methodOop=0x2b4bce08 (Interpreted frame)
- java.lang.Thread.run() @bci=11, pc=0x046a2c29, methodOop=0x2b3e1ae0 (Interpreted frame)


Thread 10: (state = BLOCKED, current Java SP = 0x070df898
)
- java.lang.Object.wait(long), pc=0x046a826f, methodOop=0x2b3d15f0 (Interpreted frame)
- java.lang.ref.ReferenceQueue.remove(long) @bci=44, pc=0x046a2923, methodOop=0x2b40a430 (Interpreted frame)
- java.lang.ref.ReferenceQueue.remove() @bci=2, pc=0x046a29fa, methodOop=0x2b40a468 (Interpreted frame)
- sun.java2d.Disposer.run() @bci=3, pc=0x046a29fa, methodOop=0x2b519a80 (Interpreted frame)
- java.lang.Thread.run() @bci=11, pc=0x046a2c29, methodOop=0x2b3e1ae0 (Interpreted frame)


Thread 6: (state = BLOCKED, current Java SP = null
)


Thread 5: (state = BLOCKED, current Java SP = 0x069cfb44
)
- java.lang.Object.wait(long), pc=0x046a826f, methodOop=0x2b3d15f0 (Interpreted frame)
- java.lang.ref.ReferenceQueue.remove(long) @bci=44, pc=0x046a2923, methodOop=0x2b40a430 (Interpreted frame)
- java.lang.ref.ReferenceQueue.remove() @bci=2, pc=0x046a29fa, methodOop=0x2b40a468 (Interpreted frame)
- java.lang.ref.Finalizer$FinalizerThread.run() @bci=3, pc=0x046a29fa, methodOop=0x2b413e10 (Interpreted frame)


Thread 4: (state = BLOCKED, current Java SP = 0x068cfbf4
)
- java.lang.Object.wait(long), pc=0x046a826f, methodOop=0x2b3d15f0 (Interpreted frame)
- java.lang.Object.wait() @bci=2, pc=0x046a2923, methodOop=0x2b3d1668 (Interpreted frame)
- java.lang.ref.Reference$ReferenceHandler.run() @bci=46, pc=0x046a2923, methodOop=0x2b413a00 (Interpreted frame)


Thread 0: (state = IN_NATIVE, current Java SP = null
)

Comments

EVALUATION Duplicate of 6494370. Can't close it as a duplicate since the subCR contains "Fixed in Build" and "Commit to Fix in Build" values. Closing it as "not reproducible".
17-11-2010
EVALUATION this bug is not regression. remove the keyword
24-08-2006
EVALUATION According to the stack traces, system app context's EDT is waiting for the next event and don't interact with applet's EDT. Also, applet's EDT (that shows the modal dialog) is not waiting on any Java object, it is waiting in the native code, so this is definitely not a Java deadlock. As for Win32 - I don't know what exact window it sends a message to, but I suspect it is a second browser window. I think the message is some kind of window activation.
05-07-2006
EVALUATION I'm a little confused by Aterm's description. let's see how many threads involved in this case. When "New Window" button is clicked, a separate UI thread is started to create a new window. So there are two browser UI thread. one runs the orignal applet, the second is for the new Window. These two UI threads are actually the main threads of plugin. So there are actually 2 main plugin thread. When user presses the button 'Show Dialog', EDT sends message to toolkit thread where dialog is created, then toolkit thread calls ShowWindow(). then win32 subsystem steps in. The question is , does win32 send WM_SHOWWINDOW to the first UI thread, or it sends that message to all UI threads in IE process? If win32 only sends msg to first UI thread, as createFrame is called in the second UI thread, the deadlock shouldn't happen. Two EDTs also are involved. EDT1 is in main AppContext. EDT2 is in applet AppContext. the second UI thread (thread 19 in Kirill's stack trace) asks EDT1(thread 15) to create Frame and wait for it. EDT2(thread 18) is running dialog. Maybe the deadlock comes from two EDT contend for AWTTreeLock.
05-07-2006
EVALUATION AWT can do nothing to get this bug fixed as the problem is mainly in Plugin code. So I'm dispatchin it back to java/java_plugin/other.
28-06-2006
WORK AROUND I'm not sure but it looks like the problem may be workarounded by configuring IE to launch each of its windows in a separate thread/process. It can be done in Control Panel -> Folder Options -> View -> Launch folder windows in a separate process.
23-06-2006
EVALUATION It seems that we have found what's going. The hang is a deadlock between 3 threads: AWT toolkit thread, AWT event-dispatching thread and Java Plugin 'main' thread (which is equal to browser thread). The hang can be reproduced with many different stack traces, sometimes it occurs in AwtDialog::ShowModal(), sometimes in AwtDialog::EndModal, sometimes in Container.addImpl() and many other places. Let's inspect the case with ShowModal() method, in Mustang. When user presses the button 'Show Dialog', a listener is notified on EDT and a modal dialog is shown, also on EDT. At the peer level this leads to the call to WDialogPeer.showModal(). In this method we enter a critical section with SyncCall and then send a message to toolkit thread using ::SendMessage(). While this message is being processed on toolkit thread, we call to ::ShowWindow(). During the call to ::ShowWindow() Win32 windowing subsystem sends a message to the browser window that it is losing the focus and waits for the browser window to process this event. At the same time an embedded frame is being created. Its creation is performed on the Java Plugin 'main' thread which is the same thread as browser window thread. One of the most frequent stack traces is when this embedded frame is being reshaped with reshapeFrame() native method. In this method we try to enter the same critical section as in showModal() and therefore wait. As Java Plugin 'main' thread is the same as browser thread, the message sent to this thread is never processed. Another possible scenario is with AwtTreeLock instead of native critical section. In particular, in 5.0 the hang occurs with AwtTreeLock. I don't know why Java Plugin creates Java embedded frames synchronously on the browser main thread. Anyway, I don't see how the problem can be fixed other than by moving the most of Plugin code into a separate thread which is definitely very risky.
23-06-2006
EVALUATION as far as I understand the problem is also reproducible with mustang. So targeting it to mustang to have it in my list.
15-06-2006
EVALUATION Latest trace produced with jre5.0u8b01 and Yokogawa testcase (please see attached 20060522_Freeze50y8_Ito.zip, provided by Kirill) shows consistent hung at modal dialog treatment in WDialogPeer (sun.awt.windows.WDialogPeer.showModal()). As of this point, I trust this problem should better be addressed by AWT members. Will reassign bug.
23-05-2006
EVALUATION The attached testcase with good stack dump is in yokogawa.zip
18-05-2006
EVALUATION I never could reproduce the problem on Hung's winXP Japanese machine. However, I was able to see the hang/lock (which is much more easily reproduced) with the suspicious testcase on my english locale winXP laptop. The hang is very consistent and easily seen with Firefox than IE, but the stack trace when problem occurs pretty consistently indicates a race condition when the new browser window (from AppletContext.showDocument) and the dialog (from JOptionPane.showOptionDialog) are both pumping event in java.awt.EventDispatchThread. The hang occurs in sun.awt.windows.WDialogPeer.showModal() which is a consequence step from JOptionPane.showOptionDialog. With Firefox, I can insert some timing in between the two events and see the problem go away. I've talked to AWT team's members about this problem. The problem seems to be more AWT than plugin. AWT is currently working on this issue. Will follow up with them and perhaps reassign this bug accordingly. Hopefully by fixing the hang seen at sun.awt.windows.WDialogPeer.endModal() will also fix the hang problem seen by Yokogawa. Attached is the testcase with which I can reproduce the hang during 2 activities -- modal dialog and EmbeddedFrame creations. With this testcase, problem is seen with both Firefox and IE on XP english, and it's seen more easily with Firefox. Traces for both FF and IE are similar when problem occurs. This isn't the original testcase from Yokogawa, but in the essence, Yokogawa's orig testcase does contain similar graphics activities as with this testcase. The situation is, I cannot reproduce the hang with orig testcase on Hung's machine. VNC to Hung's machine may have introduced timing that hides the problem, and Hung's provided traces do not contain info needed for debug purpose.
18-05-2006