JDK-6686520 : Occasional lockups with IE
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows,windows_xp,windows_vista
  • CPU: generic,x86
  • Submitted: 2008-04-10
  • Updated: 2010-09-08
  • Resolved: 2008-07-11
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 b27Fixed
Related Reports
Duplicate :  
JDK-6689774 - MouseDrag out of applet frame freezes IE
Duplicate :  
JDK-6712912 - Right click and drag out mouse cursor causes Applet to freeze
Description
A user on the Java Plug-In forum has indicated that IE 7 can lock up when the new Java Plug-In is running JOGL applets and certain user interface gestures are performed. Initial investigation did not turn up anything obvious. It is unclear whether the bug is in the Java Plug-In, the message processing in the AWT, the browser itself, or somewhere else. It is unclear whether there is a fix or workaround that can be introduced for example in the Java Plug-In.

The forum thread on which the issue was posted is

http://forums.java.net/jive/thread.jspa?threadID=38256&tstart=0
I was able to provoke this failure (right mouse button menu inducing livelock == 100% CPU consumption in the IE process) with the simplest Clock example applet from the Sun web site, so the deeper issue is unrelated to JOGL. At this point it is still unclear whether the bug is in IE, the new plug-in, or the AWT. The following stack trace was captured from the main thread of the IE process using the Visual Studio debugger while the livelock was occurring.

	ntdll.dll!7c90eb94() 	
 	user32.dll!7e418b8c() 	
 	mshtml.dll!438aff02() 	
 	mshtml.dll!4364d96e() 	
 	mshtml.dll!43778e8e() 	
 	ieframe.dll!42f9ee5c() 	
 	user32.dll!7e418b26() 	
 	user32.dll!7e4188d1() 	
 	user32.dll!7e4188da() 	
 	mshtml.dll!4368e1a7() 	
 	user32.dll!7e418734() 	
 	user32.dll!7e418816() 	
 	user32.dll!7e41f84a() 	
 	user32.dll!7e41b4c0() 	
 	user32.dll!7e41f805() 	
 	user32.dll!7e41b50c() 	
 	ntdll.dll!7c90eae3() 	
 	user32.dll!7e46cd34() 	
 	user32.dll!7e465109() 	
 	ieframe.dll!4305a552() 	
 	mshtml.dll!4374d741() 	
 	mshtml.dll!43654a89() 	
 	ieframe.dll!4304663e() 	
 	mshtml.dll!437ff69b() 	
 	mshtml.dll!437e410a() 	
 	mshtml.dll!437e40b3() 	

It is apparent from the module names that no code associated with the new plug-in is running on the stack of the browser's main thread, which in my opinion basically exonerates the new plug-in as the cause of the problem. The only problems we have seen in this area with the new plug-in have been related to causing Java modal dialogs to block the browser window.

Unfortunately a stack trace from the AWT toolkit thread in the attached JVM was not captured at the time the lockup occurred. Freezing the IE process for as long as was done caused the attached JVM to exit thinking the browser had exited. A stack trace will be captured if possible to see whether the AWT toolkit thread is busy at the time the livelock occurs.

Note that killing the attached Java process did not cause the IE process to recover. This in my opinion even more strongly indicates a bug in IE since one would expect that if it were busy looping waiting for something like a focus transfer to happen to a window in another process, then if that other process was killed then the IE process should recover.
Comments
EVALUATION Here are more details from Microsoft on the root cause and possible workarounds: -------------------- We have done some further research of the issue and I think we are beginning to understand the problem a little better. The crux of the problem is that the Java applets windows (in java.exe) receives the WM_CONTEXTMENU message. However, they do not seem to handle it and call their parents (cross process and cross thread) to handle it (through DefWndProc) and this cascades up the chain to Trident (IE) window. IE does not handle the message because probably it does not expect scenarios like this where ActiveX could create multiple crosss-thread/cross-process windows. IE thinks that it is in the middle of some ole thread synchronization and it re-posts the WM_INITMENUPOPUP message to process at a later time to prevent deadlocks and possibly to prevent RPC errors like RPC_E_CANTCALLOUT_ININPUTSYNCCALL (http://support.microsoft.com/kb/q131056). As I stated earlier, we end up reposting the message over and over again, spinning in a tight loop, causing high CPU. As for workarounds, the best thing to do would be to just handle the WM_CONTEXTMENU message yourself. You can handle it from any of the java windows in the chain. You could even discard the message, but just have a handler for it so that it does not go through DefWndProc. Another option would be to create the child windows on the same thread as the Trident window. A third option would be to make the ���Java Plug-in Control Window��� a top level window (child of desktop window) instead of Trident���s child to avoid the side effect of DefWndProc. -------------------- Handling the WM_CONTEXTMENU message in our ActiveX control window seems to be the most expedient and feasible workaround at this point.
31-05-2008
EVALUATION Here is an excerpt of an email from Microsoft with more details on the problem: --------------------------------- We have further debugged the issue and have some more details. From what we can see, here is the windows hierarchy of the applet bc65d6f8 [<null>|Internet Explorer_Server|] (thread 1) bc65dae0 [<null>|Java Plug-in Control Window|] (thread 1) bc660898 [<null>|SunAwtFrame|] (thread 2) bc660b60 [<null>|SunAwtCanvas|] (thread 2) bc660c58 [<null>|SunAwtCanvas|] (thread 2) thread 1: the tab window thread thread 2: java runtime/applet thread It appears that when IE spikes cpu, we are in the middle of processing an incoming cross-thread message. We in fact end up reposting the message (WM_INITMENUPOPUP) over and over again, spinning in a high cpu loop. When we started backtracking to see who was sending messages to the Internet Explorer_Server window we saw that a Java thread calls PeekMessage after creating its windows. PeekMessage call ends up sending WM_PARENTNOTIFY notifications to our IE window (it actually walks up the parent chain and sends this notification to every node), causing us to spin in a tight loop. These could be potential workarounds: 1) Don't call PeekMessage or 2) Don't create windows parented to Trident or 3) Create the Applet windows with WS_EX_NOPARENTNOTIFY style --------------------------------- Creating our ActiveX control window with the WS_EX_NOPARENTNOTIFY style seems like the most viable workaround -- we do not have control over the window styles of windows created by the AWT. Hopefully this will break the message cycle.
21-05-2008
EVALUATION We have opened a CSS-SR (Support Request) with Microsoft regarding this issue. Microsoft has reproduced the issue in house and is continuing to investigate it. At the current time it is unclear whether this is a bug in the Java Plug-In. Since there is no clear fix on the Java Plug-In side at this time we are retargeting this to a later release.
15-05-2008