JDK-6555628 : Repeatedly open and close an applet freezes IE
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 5.0u12
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows,windows_xp
  • CPU: x86
  • Submitted: 2007-05-10
  • Updated: 2014-02-27
  • Resolved: 2007-06-13
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
5.0u14 b01Fixed
Related Reports
Duplicate :  
JDK-6553150 - Plugin leaks parentless awt frames
Description
Tested jre:           1.5.0_12-b03
       OS/Browser:    XP-pro(sp2)/ IE 6

Problem:  
-------
Repeatedly open and close an applet freezes the Internet Explorer in 1.5.0_12. It appears to be a regression as it is OK in 1.5.0_11-b03-fcs

Attached files:
--------------
* Test case: Yokogawa <TC02-01.tar> 
* Freeze dump log: <PID-2316__IEXPLORE.EXE__Date_04-27-2007__Time_10-19-47AM.log>

Steps to reproduce:
------------------
1) Extract all the files from attached <TC02-01.tar>
2) Using IE to load <TC02-01_Top.html>
3) Click 'Open a page" link 
4) A page includes an applet should be opened
5) Close the page in 4)

Repeatedly do step 3 to step 5

The browser hang some time between 24-hour running interval (sometimes, it hang just after a few tries). Please contact submitter for more infomration if running in reliability mode.
When the problem occurs, java console is completely frozen and its content is invisible. Both browser and Java console can only be killed via Windows task manager.
Comments
EVALUATION It looks a thread (95c) which is doing user32!NtUserDestroyWindow locked a Critical Section. Other threads including the browser main thread is waiting to enter that CS. Something wrong with DestroyWindow Call. A possible scenario is that it may deadlock with awt toolkit thread, since the toolkit thread is waiting for the CS owned by thread 95c. Below is some output from windbg. A detailed output is attached in the bug report 0:000> !locks CritSec ntdll!LdrpLoaderLock+0 at 7c97c0d8 LockCount 11 RecursionCount 1 OwningThread 95c EntryCount 23 ContentionCount 23 *** Locked CritSec +114d854 at 0114d854 LockCount 0 RecursionCount 1 OwningThread 95c EntryCount 0 ContentionCount 0 *** Locked 0:000> ~~[95c] s eax=00000000 ebx=7d4a0000 ecx=0000095c edx=77605688 esi=0114d820 edi=0114d854 eip=7c90eb94 esp=09f2fe90 ebp=09f2feac iopl=0 nv up ei pl zr na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 ntdll!KiFastSystemCallRet: 7c90eb94 c3 ret 0:024> kb ChildEBP RetAddr Args to Child 09f2fe8c 77d4e672 7d58bb3d 0bc10124 00000000 ntdll!KiFastSystemCallRet 09f2feac 7d50fc2e 7d4a0000 00000003 00000000 user32!NtUserDestroyWindow+0xc 09f2fecc 7d50fbd8 7d4a0000 00000003 00000000 mshtml!_DllMainCRTStartup+0x52 09f2fee4 7c9011a7 7d4a0000 00000003 00000000 mshtml!_DllMainStartup+0x27 09f2ff04 7c919213 7d50fba9 7d4a0000 00000003 ntdll!LdrpCallInitRoutine+0x14 09f2ff7c 7c80cce7 7c910732 00000005 0023c6c8 ntdll!LdrShutdownThread+0xd7 09f2ffb4 7c80b510 00000001 7c910732 00000005 kernel32!ExitThread+0x3e 09f2ffec 00000000 77832319 0023c6c8 00000000 kernel32!BaseThreadStart+0x3c awt toolkit thread looks like: 14 Id: 634.894 Suspend: 1 Teb: 7ffac000 Unfrozen ChildEBP RetAddr Args to Child 0482f490 7c90e9c0 7c91901b 00000878 00000000 ntdll!KiFastSystemCallRet 0482f494 7c91901b 00000878 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc 0482f51c 7c90104b 0197c0d8 7c9131dc 7c97c0d8 ntdll!RtlpWaitForCriticalSection+0x132 0482f524 7c9131dc 7c97c0d8 c0150008 00000001 ntdll!RtlEnterCriticalSection+0x46 0482f560 7c916298 00000001 00000000 0482f5c0 ntdll!LdrLockLoaderLock+0xea 0482f7fc 7c801bb9 00213cc8 0482f848 0482f828 ntdll!LdrLoadDll+0xd6 0482f864 77d6dcb6 0482f8c8 00000000 00000008 kernel32!LoadLibraryExW+0x18e 0482f890 7c90eae3 0482f8a0 00000080 00000080 user32!__ClientLoadLibrary+0x32 0482f91c 77d493c6 77d49385 0482f9a8 00000000 ntdll!KiUserCallbackDispatcher+0x130482f948 77d493df 0482f9a8 00000000 00000000 user32!NtUserPeekMessage+0xc 0482f974 6d0e5eb3 0482f9a8 00000000 00000000 user32!PeekMessageW+0xbc 0482f98c 6d0e5e07 0482f9a8 6d0e5ea0 6d133158 awt!AwtToolkit::CommonPeekMessageFunc+0x13 0482f9c0 6d0e5c95 6d0e5ea0 01befa20 2b35e360 awt!AwtToolkit::PumpWaitingMessages+0x27 0482f9d4 6d0e6c3e 6d0e5e70 6d0e5ea0 01befa20 awt!AwtToolkit::MessageLoop+0x25 0482fab4 6d6c7599 0482fae8 0482fc8c 0000000a awt!Java_sun_awt_windows_WToolkit_eventLoop+0x4e 0482fb30 6d71fbb2 0000000a 00000000 0482fbe4 jvm!JavaCalls::call_helper+0x12b 0482fb74 6d6c746a 6d6c746e 0482fc84 0482fb98 jvm!os::os_exception_wrapper+0x5e 0482fb8c 6d6c718e 0482fc84 04346020 0482fbe4 jvm!JavaCalls::call+0x1b 0482fbc4 6d6c71c7 0482fc84 04346014 6d7c33ec jvm!JavaCalls::call_virtual+0x6f 0482fc40 6d6e2048 0482fc84 04346010 04346014 jvm!JavaCalls::call_virtual+0x31 0482fc94 6d7510d8 01befa20 01befa20 01befa20 jvm!thread_entry+0x71 0482fcc0 6d7510a6 04346520 6d71d283 00000000 jvm!JavaThread::thread_main_inner+0x30 0482fcc8 6d71d283 00000000 00000000 00000000 jvm!JavaThread::run+0x57 0482ff80 77c3a3b0 01befa20 00135da0 00030000 jvm!_start+0x6c 0482ffb4 7c80b50b 01bee460 00135da0 00030000 msvcrt!_endthreadex+0xa9 0482ffec 00000000 77c3a341 01bee460 00000000 kernel32!BaseThreadStart+0x37
24-05-2007