United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7019819 bare oop in ciField
JDK-7019819 : bare oop in ciField

Details
Type:
Bug
Submit Date:
2011-02-15
Status:
Closed
Updated Date:
2011-04-24
Project Name:
JDK
Resolved Date:
2011-04-24
Component:
hotspot
OS:
solaris_10
Sub-Component:
compiler
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs21
Fixed Versions:
hs21 (b03)

Related Reports
Backport:
Relates:

Sub Tasks

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

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.
                                     
2011-02-15
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1957c1478794
                                     
2011-02-16



Hardware and Software, Engineered to Work Together