JDK-6711100 : 64bit fastdebug server vm crashes with assert(_base == Int,"Not an Int")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs11,hs14
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2008-06-05
  • Updated: 2012-10-01
  • Resolved: 2011-03-08
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.
JDK 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Duplicate :  
JDK-6756778 - Segmentation fault with C2
Duplicate :  
JDK-6712880 - 64bit server jvm fails with assertion "return value must be well defined"
Duplicate :  
JDK-6597109 - "live value must not be garbage" assertion failure
Relates :  
JDK-6799693 - Server compiler leads to data corruption when expression throws an Exception
Relates :  
JDK-6589186 - 20070719212032.jrose.6337834 putback produces amd64 jvmg error: Bad immediate dominator info
Description
64bit fastdebug server vm crashes with assert(_base == Int,"Not an Int")

The crash is reproduced starting from hs11-b08 (jdk7b22)

hs11-b08:
#  Internal Error (/BUILD_AREA/jdk7/hotspot/src/share/vm/opto/type.hpp:958), pid=14680, tid=1083214144
#  Error: assert(_base == Int,"Not an Int")
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b08-fastdebug compiled mode linux-amd64)

hs13-b02:
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/tmp/jprt-jprtadm/temp/P1/B/224246.rasbold/source/src/share/vm/opto/type.hpp:1035), pid=14739, tid=1084266816
#  Error: assert(_base == Int,"Not an Int")
#
# Java VM: OpenJDK 64-Bit Server VM (13.0-b02-2008-06-03-224246.rasbold.hs-merge-fastdebug compiled mode linux-amd64 compressed oops)



The problem seems to be different than reported in 6646015 (fixed in hs13-b01).
The tests fail the same way but test case from 6646015 doesn't fail anymore,
new testcase continues to fail with latest hs13-b02 as well.
So, it seems to be the different problem.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8261ee795323
17-09-2008
EVALUATION The problem is based in load_array_length(), which may return the length input to the ArrayAllocateNode. If load_array_length() identifies such an ArrayAllocateNode, a CastII narrowing the type should be added, with control input being the allocate node.
11-06-2008
EVALUATION Optimization of LoadRangeNode to return the actual length loses the type information that says that it must always be positive. This means that in some cases range checks can't be folded immediately. In this particular case a constant -1 is used as an index when the length of the array is some value which isn't known to be postive. So the range check doesn't fold away but the array index expression collapses to top because of the negative value. That causes top to leak into JVMState causes various assertions to trigger. This could be fixed a CastII into the use for the CmpU node or by special casing this part of the test.
05-06-2008