JDK-4951940 : Win: Server VM crashes with test/java/util/Date/DateGregorianCalendarTest.java
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.1_06,1.4.2_01,1.4.2_02,5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,linux,linux_redhat_2.1,linux_suse_sles_8.2,solaris_8,solaris_9,solaris_10,windows_2000,windows_xp generic,linux,linux_redhat_2.1,linux_suse_sles_8.2,solaris_8,solaris_9,solaris_10,windows_2000,windows_xp
  • CPU: x86,sparc
  • Submitted: 2003-11-11
  • Updated: 2004-09-21
  • Resolved: 2003-12-01
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
1.4.2_05 05Fixed
Related Reports
Duplicate :  
JDK-4955023 - REGRESSION: JCK1.5-runtime api/java_util/zip/ZipEntry/index.html#ZipEntry1 fails
Duplicate :  
JDK-4957151 - regression java/util/TimeZone/TimeZoneRegression.java failed on AMD 64
Duplicate :  
JDK-4951933 - Linux: Server VM crashes with test/java/util/Date/DateGregorianCalendarTest.java
Duplicate :  
JDK-4952992 - Assert/SEGV in C2 running jbb on Solaris x86
Duplicate :  
JDK-4954304 - Regression java/util/Date/DateGregorianCalendarTest.java is failing
Relates :  
JDK-4946403 - [1.3.1_09] crash in C2 compiler at AddNode::Ideal
Relates :  
JDK-5048441 - Intermittent crashes in Java MarkSweep garbage collection methods
Relates :  
JDK-5067347 - dead code/loops checks and elimination.
Relates :  
JDK-5040973 - SIGSEGV in Type*Type::meet(const Type*)const+0x0
Relates :  
JDK-4964653 - VM/C2 crashes when running a java program on amd64 (and sparc v9)
Relates :  
JDK-5035395 - assert in DWhet test with -server -Xcomp on sparc
Relates :  
JDK-4951717 - test/java/util/Date/DateGregorianCalendarTest.java hangs
Description
Server VM crashes with running test/java/util/Date/DateGregorianCalendarTest.java.

$ java -showversion -server DateGregorianCalendarTest
java version "1.5.0-internal"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-internal-okutsu_06
_nov_2003_13_17)
Java HotSpot(TM) Server VM (build 1.5.0-beta-b26, mixed mode)

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d905ff5, pid=988, tid=5920
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0-beta-b26 mixed mode)
# Problematic frame:
# V  [jvm.dll+0x1d5ff5]
#
# An error report file with more information is saved as hs_err_pid988.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/cgi-bin/bugreport.cgi
#

hs_err_pid988.log:

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d905ff5, pid=988, tid=5920
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0-beta-b26 mixed mode)
# Problematic frame:
# V  [jvm.dll+0x1d5ff5]
#

---------------  T H R E A D  ---------------

Current thread (0x00965450):  JavaThread "CompilerThread0" daemon [_thread_in_native, id=5920]

siginfo: ExceptionCode=0xc0000005, reading address 0x0000000c

Registers:
EAX=0x00918fc8, EBX=0x00001df9, ECX=0x00000010, EDX=0x00000010
ESP=0x00fdf2fc, EBP=0x019ec2d8, ESI=0x00000000, EDI=0x00000010
EIP=0x6d905ff5, EFLAGS=0x00010202

Top of Stack: (sp=0x00fdf2fc)
0x00fdf2fc:   00fdf3c4 017416d4 6d92e1f1 00fdf3c4
0x00fdf30c:   019ec2d8 0000000d 00fdf504 0165b860
0x00fdf31c:   6d92e027 0165b860 6d9ca718 00fdf998
0x00fdf32c:   00fdf84c 00000000 00fdf3c4 6d7a3f49
0x00fdf33c:   6d9ca718 00fdf998 009655d8 01a64fa8
0x00fdf34c:   01a67500 01a6cf9c 00000000 00000000
0x00fdf35c:   00000001 680aa068 00000000 00000000
0x00fdf36c:   01a64fa8 01a674f8 00000000 6d8042f6 

Instructions: (pc=0x6d905ff5)
0x6d905fe5:   75 4d 83 e2 1f 8b ca 75 07 8b c6 5f 5e c2 04 00
0x6d905ff5:   8b 7e 0c 8b 76 10 8b d7 8b c6 d3 ea d3 e8 85 f6 


Stack: [0x00ee0000,0x00f20000),  sp=0x00fdf2fc,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x1d5ff5]


Current CompileTask:
opto: 53  !   DateGregorianCalendarTest+1.run()V (341 bytes)


---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x0095fb80 JavaThread "Thread-2" [_thread_in_vm, id=5164]
  0x00962e30 JavaThread "Thread-1" [_thread_blocked, id=1824]
  0x00962690 JavaThread "Thread-0" [_thread_blocked, id=4060]
  0x009a0200 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=5232]
  0x0099ef58 JavaThread "CompilerThread1" daemon [_thread_blocked, id=4760]
=>0x00965450 JavaThread "CompilerThread0" daemon [_thread_in_native, id=5920]
  0x00966d30 JavaThread "AdapterThread" daemon [_thread_blocked, id=6056]
  0x00966120 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=1296]
  0x00956d78 JavaThread "Finalizer" daemon [_thread_blocked, id=4220]
  0x00956100 JavaThread "Reference Handler" daemon [_thread_blocked, id=140]
  0x00035f28 JavaThread "main" [_thread_blocked, id=2588]

Other Threads:
  0x00954120 VMThread [id=4100]
  0x009a1300 WatcherThread [id=5424]

VM state:synchronizing (normal execution)

VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
[0x00035580/0x0000072c] Safepoint_lock - owner thread: 0x00954120
[0x000355b0/0x00000724] Threads_lock - owner thread: 0x00954120
[0x00035730/0x000006e8] Heap_lock - owner thread: 0x0095fb80

Heap
 def new generation   total 576K, used 512K [0x63f30000, 0x63fd0000, 0x64640000)
  eden space 512K,  99% used [0x63f30000, 0x63faffc0, 0x63fb0000)
  from space 64K,   1% used [0x63fc0000, 0x63fc03e8, 0x63fd0000)
  to   space 64K,   0% used [0x63fb0000, 0x63fb0000, 0x63fc0000)
 tenured generation   total 1408K, used 141K [0x64640000, 0x647a0000, 0x67f30000)
   the space 1408K,  10% used [0x64640000, 0x646635a0, 0x64663600, 0x647a0000)
 compacting perm gen  total 16384K, used 2217K [0x67f30000, 0x68f30000, 0x6d730000)
   the space 16384K,  13% used [0x67f30000, 0x6815a500, 0x6815a600, 0x68f30000)
No shared spaces configured.

Dynamic libraries:
0x00400000 - 0x00407000         M:\ws2\tiger.i18n\build\windows-i586\bin\java.EXE
0x77f50000 - 0x77ff7000         C:\WINNT\System32\ntdll.dll
0x77e60000 - 0x77f46000         C:\WINNT\system32\kernel32.dll
0x77dd0000 - 0x77e5d000         C:\WINNT\system32\ADVAPI32.dll
0x78000000 - 0x78086000         C:\WINNT\system32\RPCRT4.dll
0x77c10000 - 0x77c63000         C:\WINNT\system32\MSVCRT.dll
0x6d730000 - 0x6da6e000         M:\ws2\tiger.i18n\build\windows-i586\bin\server\jvm.dll
0x77d40000 - 0x77dcc000         C:\WINNT\system32\USER32.dll
0x77c70000 - 0x77cb0000         C:\WINNT\system32\GDI32.dll
0x76b40000 - 0x76b6c000         C:\WINNT\System32\WINMM.dll
0x76390000 - 0x763ac000         C:\WINNT\System32\IMM32.DLL
0x629c0000 - 0x629c8000         C:\WINNT\System32\LPK.DLL
0x72fa0000 - 0x72ffa000         C:\WINNT\System32\USP10.dll
0x10000000 - 0x10007000         M:\ws2\tiger.i18n\build\windows-i586\bin\hpi.dll
0x76bf0000 - 0x76bfb000         C:\WINNT\System32\PSAPI.DLL
0x008a0000 - 0x008ab000         M:\ws2\tiger.i18n\build\windows-i586\bin\verify.dll
0x008b0000 - 0x008cc000         M:\ws2\tiger.i18n\build\windows-i586\bin\java.dll
0x008d0000 - 0x008de000         M:\ws2\tiger.i18n\build\windows-i586\bin\zip.dll

VM Arguments:
java_command: DateGregorianCalendarTest

Environment Variables:
PATH=T:/bin;T:/bin;T:/bin;C:\WINNT\system32;C:\WINNT;C:\WINNT\system32\WBEM;C:\mksnt;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\PROGRA~1\MICROS~2\Common\Tools\WinNT;C:\PROGRA~1\MICROS~2\Common\MSDev98\Bin;C:\PROGRA~1\MICROS~2\Common\Tools;C:\PROGRA~1\MICROS~2\VC98\bin;C:\Program Files\Support Tools\;C:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT;C:\Program Files\Microsoft VisualStudio\Common\MSDev98\Bin;C:\Program Files\Microsoft Visual Studio\Common\Tools;C:\Program Files\Microsoft Visual Studio\VC98\bin;C:\Program Files\Adabas\bin;C:\Program Files\Adabas\pgm;C:\ispell\bin
USERNAME=okutsu
SHELL=C:/mksnt/sh.exe
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 6 Model 8 Stepping 3, GenuineIntel


---------------  S Y S T E M  ---------------

OS: Windows XP Build 2600 Service Pack 1

CPU:total 1(active 1) family 6, cmov, cx8, fxsr, mmx, sse

Memory: 4k page, physical 260400k(12292k free), swap 771644k(408052k free)


Also affects nsk test:

jit/common/misctests/whet

(intermittently) running on x86 solaris mrwhipple.east.


###@###.### 2003-11-19
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_05 generic tiger-beta FIXED IN: 1.4.2_05 tiger-beta INTEGRATED IN: 1.4.2_05 tiger-beta
22-09-2004
SUGGESTED FIX Add missing check for a dead loop into the Ideal() method for URShiftINode, AddPNode, MinINode. Return the C->top() node in case of a dead loop. ###@###.### 2003-11-18 Fix for 1.4.2: ------- addnode.cpp ------- 2c2 < #pragma ident "@(#)addnode.cpp 1.117 03/01/23 12:14:48 JVM" --- > #pragma ident "@(#)addnode.cpp 1.118 04/01/12 12:29:33 JVM" 491a492,494 > if( addp == addp->in(Address)->is_AddP() ) { // Check for dead loop. > return phase->C->top(); > } 729a733,735 > if( l == l->in(1) ) { // Check for dead loop. > return phase->C->top(); > } 765a772,774 > if( r == r->in(2) ) { // Check for dead loop. > return phase->C->top(); > } ------- mulnode.cpp ------- 2c2 < #pragma ident "@(#)mulnode.cpp 1.115 03/11/25 16:38:31 JVM" --- > #pragma ident "@(#)mulnode.cpp 1.116 04/01/12 12:29:34 JVM" 987a988,990 > if( in(1) == in(1)->in(1) ) { > return phase->C->top(); // This code is dead. > } ------------------------------------------------------------ ###@###.### 2004-01-12 For this bug fix I missed one more dead loop check in ConvL2INode::Ideal() (opto/connode.cpp). It was fixed later for the bug 4964653.
12-01-2004
EVALUATION We create a new node URShiftINode which points to itself (it could happens inside dead loop). The assert (SEGV) happens when we are trying to access type(in(1)) (in URShiftINode::Value()) before the assignment of a type to this new node (in PhaseIterGVN::transform_old()). This is not a regression. I verified it with b28 JDK and previous JVMs down to b18. All have the same problem. ###@###.### 2003-11-12 The new SDK code has the method Calendar::setFieldsComputed() which contains the ">>>" (unsigned right shift) instruction at the end of loop. This loop happens on the nevertaken branch of "if(fieldMask == ALL_FIELDS)" when this method is inlined to the GregorianCalendar::computeFields() method. So the loop becames dead. We eliminate this dead loop by removing nodes one after an other. The last node will point to itself - this is the indication of a dead loop. In our case the last node is URShiftINode. Unfortunately, we forgot to include the dead loop check for URShiftI node. And more unfortunate, the method URShiftINode::Ideal() will generate a new URShiftI node each time it see the previous node is also URShiftI node without checking that it is the same node. So we are creating the new URShiftI node which after replacing old one will point to itself. This new node don't have assigned type, so when we try to determing the type of it's inputs "type(in(1))" we have this assert. We were lucky that we didn't hit this before. The problem appears only on x86 because we have FreqInlineSize == 325 there and ==100 on sparc. So that setFieldsComputed() is not inlined on sparc. Setting FreqInlineSize == 325 on sparc also shows this problem. ###@###.### 2003-11-1
01-11-2003