JDK-4651825 : 64 bit VM crash: assert(obj->is_oop(), "sanity check")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.1
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,solaris_8
  • CPU: generic,sparc
  • Submitted: 2002-03-13
  • Updated: 2002-03-15
  • Resolved: 2002-03-15
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
64 bit VM crash when running runThese tests with VM option '+DeoptimizeALot'.
It pass with client/server VM, only crash  with 64-bit VM.

Test cases failed:
 
nsk/jvmdi/events/fieldmod001 
nsk/jvmdi/SetFieldModificationWatch/setfmodw005       
nsk/jdi/ModificationWatchpointEvent/_itself_/mwevent001 
nsk/jdi/WatchpointEvent/valueCurrent/valuecur001
nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe001
nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe002
nsk/jdi/WatchpointEvent/_itself_/wevent001 

To reproduce the problem:
1. cd /net/jano/export/disk20/GammaBase/Bugs/[bug ID]
2. ksh rerun.sh

minifridge:crash-95$ cat rerun.sh 
#!/bin/sh -f
uname -a
/net/sqesvr.sfbay/export/vsn/VM/hopper/pit/jdk/b04/solsparc/bin/java -version
/net/sqesvr.sfbay/export/vsn/VM/hopper/pit/jdk/b04/solsparc/bin/java -d64 -Xss4m -XX:+DeoptimizeALot -classpath /net/sqesvr/export/vsn/VM/testbase/runThese/classes $* runThese -thread 2 -repeat 2 -iter 1 -D:gc=5 -D:TESTBASE=/net/sqesvr/export/vsn/VM/testbase/runThese/tests -runList runList.dat
minifridge:crash-95$ ksh rerun.sh 
SunOS minifridge 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-Enterprise
java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b04)
Java HotSpot(TM) Client VM (build 20020308105420.jmasa.baseline-fastdebug1-debug, mixed mode)
VM option '+DeoptimizeALot'
......................................
[Enter:private117]
......................................
[Enter:private13]
#
# HotSpot Virtual Machine Error, assertion failure
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20020308105420.jmasa.baseline-fastdebug-debug mixed mode)
#
# assert(obj->is_oop(), "sanity check")
#
# Error happened during: deoptimize-all
#
# Error ID: /net/balvenie.sfbay/export/imgr_home/ws/20020308105420.jmasa.baseline/src/share/vm/runtime/handles.cpp, 16 [ Patched ]
#
# Problematic Thread: prio=5 tid=0x10027ad88 nid=0xe waiting on monitor 
#
Dumping core....
rerun.sh[4]: 22980 Abort(coredump)

Comments
EVALUATION During bytecode parsing, around bci 796 a merge into bci 796 inspects the liveness of all 34 locals. The liveness info reports local 0 is now dead (even though it's not). Local 0 is then set to TOP. Then it's loaded onto the JVM stack. Then it's uncommon-trapped. During deopt, we discover a stack slot with type T_CONFLICT (the dead local 0). It's not legal to have a T_CONFLICT on the JVM stack. It's surely a dup of the other bad liveness info bug. Note the similarities, large method (900+ bytecodes), many straightforward loops. The liveness info is stored in generic BitMap structures which are polymorphic based on size_t; 32 or 64 bit words depending on build. Since this is a V9-only bug perhaps there's not enough storage being allocated, and it's getting stomped? Right after the liveness info reported dead for local 0, memory was filled with 0xabababab. Perhaps the bitmap was right near the edge of allocated memory and not made big enough? ###@###.### 2002-03-14
14-03-2002