JDK-7019819 : bare oop in ciField
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs21
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2011-02-15
  • Updated: 2011-04-24
  • Resolved: 2011-04-24
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 7 Other
7Fixed hs21Fixed
Related Reports
Relates :  
JDK-6354181 - nsk.logging.stress.threads.scmhml001 fails assertion in "src/share/vm/oops/instanceKlass.cpp, 111"
Description
We've seen several nightly crashes like this:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xffffffff7d13aff8, pid=1043, tid=11
#
# JRE version: 7.0-b129
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b02-internal-201102142244.kvn.main_to_comp-fastdebug mixed mode solaris-sparc compressed oops)
# Problematic frame:
# V  [libjvm.so+0x53aff8]  ciObject*ciObjectFactory::get(oop)+0x10b8
#
# Core dump written. Default location: /export/local/42660.JDK7.NIGHTLY.VM+solaris-sparcv9_vm_server_mixed_nsk.stress.testlist/results/ResultDir/jck122001/core or core.1043
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Stack: [0xffffffff5df00000,0xffffffff5e000000],  sp=0xffffffff5dff6bd0,  free space=986k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x53aff8]  ciObject*ciObjectFactory::get(oop)+0x10b8;;  ciObject*ciObjectFactory::get(oop)+0x10b8
V  [libjvm.so+0x4f9210]  void ciField::initialize_from(fieldDescriptor*)+0xc90;;  void ciField::initialize_from(fieldDescriptor*)+0xc90
V  [libjvm.so+0x4f83f0]  ciField::ciField #Nvariant 1(fieldDescriptor*)+0x628;;  ciField::ciField(fieldDescriptor*)+0x628


Vladimir caught this in the debugger and it appeared that the klassOop in this line:

    klassOop k = _holder->get_klassOop();

went bad at it's use here:

        oop o = k->obj_field(_offset);
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1957c1478794
16-02-2011
EVALUATION The call to type() can call compute_type which can call into ciEnv::get_klass_by_name_impl. There are potential GC points in there but it's likely we weren't hitting them reliably previously. The fix for 6354181 added a MutexLocker for Compile_lock in there which creates a more reliable place for a safepoint to occur so it's likely the reason this became visible. The fix is simply to handleize the klassOop so it can't go stale.
15-02-2011