JDK-6386537 : Deadlock occurs between Java Plug-in and Windows in 1.3.1_06
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.3.1_06,5.0u7,5.0u8,6u1
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-02-16
  • Updated: 2010-12-03
  • Resolved: 2006-08-02
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 Other JDK 6
1.3.1_20Resolved 1.4.2_14Resolved 6 b94Fixed
Related Reports
Duplicate :  
JDK-6433650 - Internet Explorer is frozen after open and close repeatedly for 20-30 minute in 5.0u7-b02
Description
There seems some trouble between Java Plug-in and Windows.

CONFIGURATION :
  OS  : WindowsXP Pro SP2
         Internet Explorer 6.0 SP2
  JDK : 1.3.1_06

The licensee sends their report also.
As for all the log, please look at the attached log files, logs.zip.

=========== Licensee's Report ================

BEHAVIOR :

ThreadID (0x14e4) having ntdll!LdrpLoaderLock is suspended 
in Safepoint (JavaVM).

------
0:040> !locks

CritSec ntdll!LdrpLoaderLock+0 at 7C9BC0D8
LockCount          11             ~~~~~~~~
RecursionCount     1
OwningThread       14e4
EntryCount         36
ContentionCount    36
*** Locked

0:040> ~.
. 40  Id: 14e0.14e4 Suspend: 0 Teb: 7ff8b000 Unfrozen
      Priority: 0  Priority class: 8
0:040> !bt
 Thread  Id: 14e0.14e4  Teb: 7ff8b000
ChildEBP RetAddr  Args to Child
0afafdfc 7c94e9c0 7c8025db 00000710 00000000 ntdll!KiFastSystemCallRet
0afafe00 7c8025db 00000710 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
0afafe64 7c802542 00000710 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xa8
0afafe78 08048d52 00000710 ffffffff 080484eb kernel32!WaitForSingleObject+0x12
0afafe84 080484eb 0b495d30 08054b8a 0b495d30 jvm!Mutex::wait_for_lock_implementation+0xb
0afafe8c 08054b8a 0b495d30 0b495de0 0afafee4 jvm!Mutex::jvm_raw_lock+0x15
0afafe9c 0802ae0e 00000000 00000000 057cc0e4 jvm!SafepointSynchronize::block+0x136
0afafeac 6d30200d 080a8c9c 6d301de6 00000003 jvm!jni_DetachCurrentThread+0x2d
0afafee4 7c9411a7 6d130000 00000003 00000000 jpishare!Java_sun_plugin_JavaRunTime_ConsoleStatus+0x6bb
0afaff04 7c959213 6d144b13 6d130000 00000003 ntdll!LdrpCallInitRoutine+0x14
0afaff7c 7c80cce7 00000002 00000002 038ccc38 ntdll!LdrShutdownThread+0xd7
0afaffb4 7c80b510 00000000 00000002 00000002 kernel32!ExitThread+0x3e
0afaffec 00000000 6d135a01 038ccc38 00000000 kernel32!BaseThreadStart+0x3c
-----


ThreadID (0xbcc) is waiting for ntdll!LdrpLoaderLock.
Also, according to the follwoing messages, that has not entered into  "safepoint".

----
"AppContextCreator" prio=??? tid=0xb52ee90 nid=0xbcc runnable 
  _thread_state    = 0x00000002 (_thread_new)
  _safepoint_state = 0x0b52ef48
       _type       = 0x00000000 (_running)
       _thread     = 0x0b52ee90
       _addr       = 0x00000000
       _handle     = 0x0715b408
       _codeBuffer = 0x00000000
       _stop_state = 0x00000002 (_thread_new)
       _stop_pc    = 0x00000000

  41  Id: 14e0.bcc Suspend: 0 Teb: 7ff95000 Unfrozen
ChildEBP RetAddr  Args to Child              
079dfc10 7c94e9c0 7c95901b 00000a18 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
079dfc14 7c95901b 00000a18 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc (FPO: [3,0,0])
079dfc9c 7c94104b 019bc0d8 7c967357 7c9bc0d8 ntdll!RtlpWaitForCriticalSection+0x132 (FPO: [Non-Fpo])
079dfca4 7c967357 7c9bc0d8 079dfd30 00000000 ntdll!RtlEnterCriticalSection+0x46 (FPO: [1,0,0])
                  ~~~~~~~~
079dfd1c 7c94eac7 079dfd30 7c940000 00000000 ntdll!_LdrpInitialize+0xf0 (FPO: [Non-Fpo])
00000000 00000000 00000000 00000000 00000000 ntdll!KiUserApcDispatcher+0x7
------

ThreadID(0xa84) (VMThread of JavaVM) is waiting when ThreadID (0xbcc) enters into safepoint.


-----
 Thread  Id: 14e0.a84  Teb: 7ffa4000
ChildEBP RetAddr  Args to Child
0631fe84 7c94d85c 7c8023ed 00000000 0631feb8 ntdll!KiFastSystemCallRet
0631fe88 7c8023ed 00000000 0631feb8 00000000 ntdll!NtDelayExecution+0xc
0631fee0 7c802451 00000001 00000000 0631ff1c kernel32!SleepEx+0x61
0631fef0 0804dd83 00000001 08054981 0000f8c3 kernel32!Sleep+0xf
0631fef8 08054981 0000f8c3 00000000 057ed3c8 jvm!os::yield_all+0x8
0631ff1c 0806fd3e 057dac10 057b3678 057c1938 jvm!SafepointSynchronize::begin+0x90
0631ff6c 0806fb08 00380000 057b0280 0804ccbb jvm!VMThread::loop+0x11b
0631ff78 0804ccbb 0631ffb4 77bea3b0 057b3678 jvm!VMThread::run+0x52
0631ff80 77bea3b0 057b3678 00380000 7c950732 jvm!os::create_thread+0x120
0631ffb4 7c80b50b 057c1938 00380000 7c950732 msvcrt!_endthreadex+0xa9
0631ffec 00000000 77bea341 057c1938 00000000 kernel32!BaseThreadStart+0x37
----

Dead lock seems to occur among above 3 threads.

===========================================
I would like to get a test case to test this scenario with Mustang. Please provide one.
Comments
EVALUATION Need a testcase to make progress. Is this bug reproducible in any other higher versions of JDK?
04-05-2006