JDK-4311720 : assertion "Not an Int"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 2.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2000-02-10
  • Updated: 2000-05-03
  • Resolved: 2000-05-03
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.3.0 sol-betaFixed
Related Reports
Relates :  
JDK-4387520 - Kestrel: HotSpot Virtual Machine Error, Unexpected Signal 11
Description

Name: dkC59003			Date: 02/10/2000


HS 2.0-rc2A (win32) crashes while trying to execute the JCK-stress test 
jck12a011 in debug mode. 
The failure was reproduced on the machine:
Pentium-II, 1 CPU, 350MHz, 128Mb RAM, WinNT 4.0, SP3
The crash is intermittent, I tried to run the test through Tonga for 6 times
and got the following results:
- the test passed once,
- 1 execution ended with EXCEPTION_ACCESS_VIOLATION:  
#
# HotSpot Virtual Machine Error, EXCEPTION_ACCESS_VIOLATION
#
# unexpected exception occurred
#
# Error ID: C:\hotspot2\src\os\win32\vm\os_win32.cpp, 729
#
# Problematic Thread: prio=5 tid=0x8c11c8 nid=0x501 runnable
#

- 4 executions ended with the assertion failure:
#
# HotSpot Virtual Machine Error, assertion failure
#
# assert(_base == Int, "Not an Int")
#
# Error ID: C:\hotspot2\src\share\vm\opto\type.hpp, 754
#
# Problematic Thread: prio=9 tid=0x853918 nid=0x3c5 runnable
#

The test nsk/stress/jck12a/jck12a011 can be found in the testbase: 
    /net/sqesvr/vsn/testbase/testbase_nsk 

To reproduce this failure, please try the script 'doit.bat' in 
the directory:
    /net/sqesvr/vsn/GammaBase/Bugs/<this_bug_number>

======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: kest-sol-beta INTEGRATED IN: kest-sol-beta
14-06-2004
EVALUATION michael.paleczny@eng 2000-02-10 Hit an assert running in debug mode with current build under JDK1.2.2: assert(Universe::is_heap(*start), "should be in heap:); Reproduced twice on different machines. > doit.bat D:\jdk1.2.2 K:\jck1.JCK-runtime-api-12a // K: == /net/jdk/export/disk8/local.java == /usr/local/java Reproduced it again. Program runs huge number of threads. In -Xcomp mode most are awaiting on the CompileBroker locks to do compiles. Oop is in the non-static oop maps for some instanceKlass. One of the oops is past the heap top and before the heap end. Being past the top is a no-no and throws an assert. Now, heap-top and heap-end aren't real close to each other. So it kinda looks like we are doing a scavenge, but we had no reason to scavenge unless somebody asked for a huge object OR we got the wrong heap-top value. The scavenge is invoked by jni_DefineClass -> class file parser -> SystemDictionary::resolve_or_fail -> blah, blah, blah-> allocate string. I suspect we moved a klass during or around an allocation and dropped some oop in the process. I'm going to reassign this to steffan for now. cliff.click@eng 2000-02-15 ================================================= michael.paleczny@eng 2000-03-08 Tested with current build, Server RC2-C+fixes Test jck12a011 PASSED under JDK1.2.2-W using Windows 98 on K7 also passed running under Windows NT on PII-266 Test once more before closing as no longer reproducible. ----------------------------------------------------------- Ran doit.bat in bugs directory. I can reproduce two different failures running with the latest main/baseline on win32 (dual processor): The test runs fine in int and mixed mode, and fine in Xcomp mode with C1. Run -Xcomp -XX:CIStart=30000 -XX:+VerifyBeforeScavenge -XX:+VerifyAfterScavenge and I get: assert( _base == Int, "Not an Int" ) Type::is_int() line 750 + 66 bytes SubINode::Ideal(PhaseGVN * 0x0e8df334, PhaseDefUse * 0x0e8df474) line 89 + 29 bytes PhaseIterGVN::transform_old(Node * 0x06523004) line 801 + 27 bytes PhaseIterGVN::optimize() line 713 + 21 bytes Compile::Optimize() line 881 Compile::Compile(ciEnv * 0x0e8dfdd0, ciScope * 0x05c29830, ciMethod * 0x05c2973c, int -1, long 1, long 1, long 0) line 381 C2Compiler::compile_method(ciEnv * 0x0e8dfdd0, ciScope * 0x05c29830, ciMethod * 0x05c2973c, int -1, long 0) line 42 CompileBroker::invoke_compiler_on_method(CompileTask * 0x07a3b308) line 1140 CompileBroker::compiler_thread_loop() line 1047 + 9 bytes compiler_thread_entry(JavaThread * 0x0077b0e8, Thread * 0x0077b0e8) line 1683 Run -Xcomp -XX:+VerifyBeforeScavenge -XX:+VerifyAfterScavenge and I get a failure in verify-before. The problematic eden area looks like: 08608FF0 00000001 <- previous valid object 08608FF4 0C4C0298 08608FF8 00000009 08608FFC 00650054 08609000 00740073 08609004 00540020 08609008 00690068 0860900C 00000073 08609010 BAADBABE <- allocated but uninitialized object 08609014 BAADBABE 08609018 BAADBABE 0860901C BAADBABE 08609020 BAADBABE 08609024 BAADBABE 08609028 00000001 <- next valid object 0860902C 0C4E8F00 08609030 08609040 08609034 00000010 08609038 00000001 0860903C 00000000 I tried moving CIStart up and got this verify-before failure consistently until I got to CIStart=30000, at which point the other error showed up. The uninitialized object is always 6 words (a java.lang.String maybe?). steffen.grarup@eng 2000-04-18 The intrinsic StrComp (string compare) was not listed in the AD file as killing flags. Also it was not flagged as a load, despite it loading memory. Not flagging it as a load but having a memory edge had it defaulting to 'store' behavior; the following heap-top-compare-vs-memory was being listed as being anti-dependent on the string-compare and was then forced before the string compare. Since flags were not listed as being killed, there was no cyclic dependency made obvious. So the system silently inserted the string-compare between the heap-top-compare and the branch to allocation-failure. Net result: a perfectly successful allocation was listed as failing, leaving an uninitialized hole in the heap. cliff.click@eng 2000-04-25
25-04-2000