JDK-6433650 : Internet Explorer is frozen after open and close repeatedly for 20-30 minute in 5.0u7-b02
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0u7,5.0u8
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-06-03
  • Updated: 2014-02-27
  • Resolved: 2006-06-22
Related Reports
Duplicate :  
JDK-6386537 - Deadlock occurs between Java Plug-in and Windows in 1.3.1_06
Relates :  
JDK-6370565 - IE browser hangs when multiple applets are reloaded several times
Description
This problem was reported by Tadayuki Baba <###@###.###> via Yokogawa Electric's escalation issue.
When IE window open and close repeatedly , IE becomes freezes for 20 minute or so.

CONFIGURATION :
 OS : WinXP(SP2, Japanese)
 JRE : jre5.0u7
      java version "1.5.0_07"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b02)
      Java HotSpot(TM) Client VM (build 1.5.0_07-b02, mixed mode, sharing)
 CPU : PentiumIII 700[MHz]
 Mem: 256 MB

REPRODUCE:
 1) Unfold the attached zip file.
 2) Modify ArcTest\testcase\top.html for your directory structure.
 3) Double click the Top.html
  IE windows appears
 4) Select "1.5.0_xx ArcTest" in pull down menu
 5) Set "5000" in t"Interval" textbox
 6) Click "Launch" button
  "ArcTest" is opened and closed automatically

After 20-30 minutes, IE will freeze.
Comments
EVALUATION Subject: Re: CR 6433650 *Escalated* david.cox, Now responsible manager P2 hotspot/garbage_coll Internet Explorer is frozen after open and close repeatedly for 20-30 minute in 5.0u7-b02 Date: Thu, 22 Jun 2006 12:45:06 -0700 From: Kirill Soshalsky <###@###.###> To: Peter B. Kessler <###@###.###> CC: Kevin Walls <###@###.###>, ###@###.###, ###@###.###, ###@###.###, ###@###.###, ###@###.###, ###@###.###, ###@###.###, ###@###.###, ###@###.###, ###@###.###, ###@###.###, ###@###.###, ###@###.### References: <4167406.1150945351674.JavaMail.sbladm@swsblss> <###@###.###> <###@###.###> Right, the log files are off since the symbol files were not used. Looking at this in windbg I can confirm this is the same problem as 6386537 ( the hang in safepointing/jni_DetachCurrentThread/LdrpLoaderLock ) which should be somewhere in plugin and/or runtime. correct stacks are attached (both pointing to the same problem): blocking for a safepoint in DllMain (in jni_DetachCurrentThread) and holding LdrpLoaderLock : ChildEBP RetAddr Args to Child 0a7dfdd4 7c90e9c0 7c8025db 0000048c 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0]) 0a7dfdd8 7c8025db 0000048c 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc (FPO: [3,0,0]) 0a7dfe3c 7c802542 0000048c ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xa8 (FPO: [Non-Fpo]) 0a7dfe50 6d794232 0000048c ffffffff 6d793427 kernel32!WaitForSingleObject+0x12 (FPO: [Non-Fpo]) 0a7dfe5c 6d793427 00000005 04d7dac0 6d7b4ae1 jvm!Mutex::wait_for_lock_implementation+0xb (FPO: [0,0,0]) (CONV: thiscall) [C:/BUILD_AREA/jdk1.5.0_08/hotspot\src\os\win32\vm\mutex_win32.cpp @ 26] 0a7dfe68 6d7b4ae1 04d7dac0 00000000 04d7dac0 jvm!Mutex::lock_without_safepoint_check+0x24 (FPO: [0,0,2]) (CONV: thiscall) [C:/BUILD_AREA/jdk1.5.0_08/hotspot\src\share\vm\runtime\mutex.cpp @ 117] 0a7dfe7c 6d7cfeac 04d7dac0 6d400000 0a7dfe9c jvm!SafepointSynchronize::block+0x15e (CONV: cdecl) [C:/BUILD_AREA/jdk1.5.0_08/hotspot\src\share\vm\runtime\safepoint.cpp @ 508] 0a7dfe8c 6d701cf7 00000000 04d7dac0 0a7dfee4 jvm!JavaThread::check_safepoint_and_suspend_for_native_trans+0x58 (CONV: cdecl) [C:/BUILD_AREA/jdk1.5.0_08/hotspot\src\share\vm\runtime\thread.cpp @ 1996] 0a7dfe9c 6d751acd 04d7dac0 00000006 0003ebcc jvm!ThreadStateTransition::transition_from_native+0x4f (CONV: cdecl) [C:/BUILD_AREA/jdk1.5.0_08/hotspot\src\share\vm\runtime\interfaceSupport.hpp @ 174] 0a7dfeac 6d4521b3 6d815b98 6d452013 00000003 jvm!jni_DetachCurrentThread+0x41 (FPO: [1,0,1]) (CONV: stdcall) [C:/BUILD_AREA/jdk1.5.0_08/hotspot\src\share\vm\prims\jni.cpp @ 2789] 0a7dfeb4 6d452013 00000003 6d405ab6 0003ebc4 jpishare!CJavaJNI::DetachCurrentThread+0xd (FPO: [0,0,0]) [../../../src/plugin/win32/jpishare/CJavaJNI.cpp @ 188] 0a7dfebc 6d405ab6 0003ebc4 6d40a715 6d400000 jpishare!CJavaVMService::DetachCurrentThread+0x1a (FPO: [1,0,1]) [../../../src/plugin/win32/jpishare/CJavaVMService.cpp @ 166] 0a7dfec4 6d40a715 6d400000 00000003 00000000 jpiexp32!DllMain+0x27 (FPO: [3,0,0]) [../../../../src/plugin/win32/com/iexplorer/DllServer.cpp @ 275] 0a7dfee4 7c9011a7 6d400000 00000003 00000000 jpiexp32!_DllMainCRTStartup+0x50 0a7dff04 7c919213 6d40a6c5 6d400000 00000003 ntdll!LdrpCallInitRoutine+0x14 0a7dff7c 7c80cce7 7c910732 00000005 0a4d99f8 ntdll!LdrShutdownThread+0xd7 (FPO: [Non-Fpo]) 0a7dffb4 7c80b510 00000001 7c910732 00000005 kernel32!ExitThread+0x3e (FPO: [Non-Fpo]) 0a7dffec 00000000 77832319 0a4d99f8 00000000 kernel32!BaseThreadStart+0x3c (FPO: [Non-Fpo]) 0:000> !locks CritSec ntdll!LdrpLoaderLock+0 at 7C97C0D8 LockCount 16 RecursionCount 1 OwningThread b50 EntryCount 18 ContentionCount 18 *** Locked This problem is consistently reproducible on various machines. thanks, Kirill
22-06-2006
EVALUATION Hung tested 5u8-b02, and the hang issue described in CR #6433650 (Yokogawa's TC04-01) can be reproducible on non HT machines. The test data indicates that the hang issue isn't caused by GDI object leak. XP-Professional (sp2) English ----------------------------- Ran 4 times on 2 different non-HT machines. IE6/Java console frozen, and corrupted display on the java console 1st: 16 hours 2nd: 2 hours 3rd: 8 hours 4th: 14 hours Average: ~ 10 hours Two log files (PID-2828* , PID-3320*) are attached. From them , it seems many threads suspend in jvm!jmm_GetLastGCStat(). so transfer this bug to vm team for futher investigation.
22-06-2006