JDK-4288182 : RC1 : Build B : 2 JCK VM tests crash with assert in os_win32.cpp. 729
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1999-11-04
  • Updated: 1999-12-01
  • Resolved: 1999-12-01
Related Reports
Relates :  
JDK-4288475 - assert(test != 0, "Unexpected object header as 0"); -Xcomp
Description
**********************Regression test not needed***************

OS : Windows NT

Mode : -Xcomp -Xint -Xmixed -classic


Test Failed : 
javasoft.sqe.tests.vm.gscl001.gscl00103.gscl00103
javasoft.sqe.tests.vm.isaf001.isaf00103.isaf00103 

NOTE : These tests doesn't fail when they run single time. If we run in stress mode then they fails in all modes including classic.


How to reproduce :
-Install JDK 1.2.2 W
-Install RC1 build B
-Map U: \\sqesvr\vsn
-Map J: \\tapas\export1\testexec
-Map T: \\vmnightly8\jdkdist
-cd U:\vsn\GammaBase\Bugs\<BugID>
-run DoIt.bat

Output with java :
==================
#
# HotSpot Virtual Machine Error, EXCEPTION_ACCESS_VIOLATION
#
# Error ID: 4F533F57494E13120E43505002D9
#

NOTE : This test passes with -classic and -Xint
Comments
EVALUATION michael.paleczny@eng 1999-11-04 The stress versions of these tests need a sanity check cliff.click@eng 1999-11-23 This test uses nested java VMs. The outer VM is just a wrapper; changing the -Xint or -classic flags on the outer VM does NOT change which inner VM is used to do the actual test. After peeling the command line apart, I got a command line for the INNER vm. I moved the jckjni_g.dll to the same bugs directory as the test: U:\GammaBase\Bugs\4288182 Then I run: java_g -Xint -cp J:\JCK-122a\classes;T:\sqe-tools2.1\javatest.jar -verify javasoft.sqe.javatest.lib.ExecJCKTestSameJVMCmd -loadDir J:\JCK-122a\classes -repeat 5 javasoft.sqe.tests.vm.gscl001.gscl00103.gscl00103 -loadLibraryAllowed This command line fails for classic, -Xint and compiled mode in the same way: a bad string is passed to jni_FindClass from the jckjni_g.dll. The strings are usually of the form "java/lang/System" or some such class-name variant. On the failing case, the string's ADDRESS is: 0x6176616a which is an invalid address. This looks like the first 4 ascii characters 'avai', so I believe the jckjni_g.dll code did an extra dereference on an error string (as in 'not available') and passed this bogus address to the VM. cliff.click@eng 1999-11-23 Udayd, for a complete set of tests that should not be part of the Stress run of JCK122 see bug id: 4194802. These two tests are also in it. mohammad.gharahgouzloo@Eng 1999-12-01
23-11-1999