JDK-8020517 : SIGSEGV in ciEnv::get_constant_by_index_impl
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs25
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2013-07-15
  • Updated: 2019-09-13
  • Resolved: 2014-05-23
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 8 JDK 9
8u20Resolved 9Resolved
Related Reports
Duplicate :  
JDK-8028497 - SIGSEGV at ClassLoaderData::oops_do(OopClosure*, KlassClosure*, bool)
Duplicate :  
JDK-8023824 - EXCEPTION_ACCESS_VIOLATION in ciEnv::get_constant_by_index_impl
Relates :  
JDK-8028497 - SIGSEGV at ClassLoaderData::oops_do(OopClosure*, KlassClosure*, bool)
Description
Test name: gc/lock/jni/jnilock002 
Build: jdk 1.8.0 b97, hotspot 25.0 b39

Excerpt from hs_err:
#  SIGSEGV (0xb) at pc=0xf6e6b0ae, pid=10175, tid=3821009776
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b97) (build 1.8.0-ea-b97)
# Java VM: Java HotSpot(TM) Client VM (25.0-b39 compiled mode, sharing linux-x86 )
# Problematic frame:
# V  [libjvm.so+0x1400ae]  ciEnv::get_constant_by_index_impl(constantPoolHandle, int, int, ciInstanceKlass*)+0x3e
...
Stack: [0xe3b7f000,0xe3c00000],  sp=0xe3bfe5c0,  free space=509k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1400ae]  ciEnv::get_constant_by_index_impl(constantPoolHandle, int, int, ciInstanceKlass*)+0x3e;;  ciEnv::get_constant_by_index_impl(constantPoolHandle, int, int, ciInstanceKlass*)+0x3e
V  [libjvm.so+0x14073c]  ciEnv::get_constant_by_index(constantPoolHandle, int, int, ciInstanceKlass*)+0x28c;;  ciEnv::get_constant_by_index(constantPoolHandle, int, int, ciInstanceKlass*)+0x28c
V  [libjvm.so+0x166308]  ciBytecodeStream::get_constant()+0x198;;  ciBytecodeStream::get_constant()+0x198
V  [libjvm.so+0xb9297]  GraphBuilder::load_constant()+0x27;;  GraphBuilder::load_constant()+0x27
V  [libjvm.so+0xc6853]  GraphBuilder::iterate_bytecodes_for_block(int)+0x1823;;  .L3210+0xc
V  [libjvm.so+0xc737b]  GraphBuilder::iterate_all_blocks(bool)+0xfb;;  GraphBuilder::iterate_all_blocks(bool)+0xfb
V  [libjvm.so+0xc9384]  GraphBuilder::GraphBuilder(Compilation*, IRScope*)+0x404;;  GraphBuilder::GraphBuilder(Compilation*, IRScope*)+0x404
V  [libjvm.so+0xcf77f]  IRScope::IRScope(Compilation*, IRScope*, int, ciMethod*, int, bool)+0x12f;;  IRScope::IRScope(Compilation*, IRScope*, int, ciMethod*, int, bool)+0x12f
V  [libjvm.so+0xcfa27]  IR::IR(Compilation*, ciMethod*, int)+0x77;;  IR::IR(Compilation*, ciMethod*, int)+0x77
V  [libjvm.so+0xb31ee]  Compilation::build_hir()+0xbe;;  Compilation::build_hir()+0xbe
V  [libjvm.so+0xb355c]  Compilation::compile_java_method()+0x5c;;  Compilation::compile_java_method()+0x5c
V  [libjvm.so+0xb36a4]  Compilation::compile_method()+0x54;;  Compilation::compile_method()+0x54
V  [libjvm.so+0xb3976]  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*)+0x1f6;;  Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*)+0x1f6
V  [libjvm.so+0xb48a2]  Compiler::compile_method(ciEnv*, ciMethod*, int)+0x92;;  Compiler::compile_method(ciEnv*, ciMethod*, int)+0x92
V  [libjvm.so+0x1a7c69]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd39;;  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd39
V  [libjvm.so+0x1a9a35]  CompileBroker::compiler_thread_loop()+0x545;;  CompileBroker::compiler_thread_loop()+0x545
V  [libjvm.so+0x512ca8]  compiler_thread_entry(JavaThread*, Thread*)+0x18;;  compiler_thread_entry(JavaThread*, Thread*)+0x18
V  [libjvm.so+0x519a89]  JavaThread::thread_main_inner()+0x109;;  JavaThread::thread_main_inner()+0x109
V  [libjvm.so+0x519c7e]  JavaThread::run()+0x1be;;  JavaThread::run()+0x1be
V  [libjvm.so+0x448ff9]  java_start(Thread*)+0x119;;  java_start(Thread*)+0x119
C  [libpthread.so.0+0x6a49]  abort@@GLIBC_2.0+0x6a49
Comments
Is a duplicate of JDK-8028497 with a different symptom.
23-05-2014
# Internal Error (/export/home/cphillim/hg/rt.old-oom/src/share/vm/oops/constantPool.cp p:170), pid=31236, tid=3079224176 # assert(DumpSharedSpaces || resolved_reference_length() == 0 || resolved_references() != NULL) failed: clearing this is bad # (gdb) print ik._value->print_on(tty) sun.misc.FloatingDecimal {0x80ec9010} - instance size: 2 - klass size: 74 - access: public synchronized - state: loaded - name: 'sun/misc/FloatingDecimal' (gdb) print *this $6 = {<Metadata> = {<MetaspaceObj> = {<No data fields>}, _vptr.Metadata = 0x17cd5e8, _valid = 0}, _tags = 0x80ec8440, _cache = 0x80ec9138, _pool_holder = 0x80ec9010, _operands = 0x0, _resolved_references = 0x0, _reference_map = 0x803305b8, _flags = 0, _length = 414, _saved = {_resolved_reference_length = 13, _version = 13}, _lock = 0x0} About to zero resolved_reference_length. Fixed code doesn't call remove_unshareable_info for OOM anymore.
23-05-2014
I'm pretty sure this is a duplicate of JDK-8028497 SIGSEGV at ClassLoaderData::oops_do(OopClosure*, KlassClosure*, bool) but I'm trying to reproduce it with an assertion. When we get the OOM from restore_unshareable_info() the old code used to call remove_unshareable_info() which zeros out the resolved_reference_length. In this test (not sure how) reloading FloatDecimal will think there aren't any resolved_references to allocate. void ConstantPool::remove_unshareable_info() { // Resolved references are not in the shared archive. // Save the length for restoration. It is not necessarily the same length // as reference_map.length() if invokedynamic is saved. set_resolved_reference_length( resolved_references() != NULL ? resolved_references()->length() : 0); set_resolved_references(NULL); set_lock(NULL); }
23-05-2014
This is wrong that the resolved_reference_length is zero for this class. That's why there are no resolved_references but there is the lock. The constant pool lock is allocated after the resolved_references. So there wasn't an exception while restore_unshareable_info. (gdb) p *cpool->_value $9 = {Metadata = {MetaspaceObj = {<No data fields>}, _vptr.Metadata = 0xf727fe08}, _tags = 0x80ea3878, _cache = 0x80ea44e8, _pool_holder = 0x80ea43c8, _operands = 0x0, _resolved_references = 0x0, _reference_map = 0x8032fbd8, _flags = 0, _length = 414, _saved = {_resolved_reference_length = 0, _version = 0}, _lock = 0xe2d059f8}
21-05-2014
Printing the class' state shows it's actually linked: (gdb) p cpool->_value->_pool_holder->_init_state $4 = 3 '\003' enum ClassState { allocated, // allocated (but not yet linked) loaded, // loaded and inserted in class hierarchy (but not linked yet) linked, // successfully linked/verified (but not initialized yet) being_initialized, // currently running class initializer fully_initialized, // initialized (successfull final state) initialization_error // error happened during initialization };
21-05-2014
The interesting question is: presumably we fail linking sun.misc.FloatingDecimal since ConstantPool::_resolved_references is null and the exception is propagated up to InstanceKlass::link_class which in turn returns false. Why are we compiling a method in an unlinked class? Is there a check missing for -Xcomp?
21-05-2014
We crash at: ciConstant ciEnv::get_constant_by_index_impl(constantPoolHandle cpool, int pool_index, int cache_index, ciInstanceKlass* accessor) { bool ignore_will_link; EXCEPTION_CONTEXT; int index = pool_index; if (cache_index >= 0) { assert(index < 0, "only one kind of index at a time"); oop obj = cpool->resolved_references()->obj_at(cache_index); dereferencing the resolved_references array because it's null: (gdb) p *cpool->_value $9 = {Metadata = {MetaspaceObj = {<No data fields>}, _vptr.Metadata = 0xf727fe08}, _tags = 0x80ea3878, _cache = 0x80ea44e8, _pool_holder = 0x80ea43c8, _operands = 0x0, _resolved_references = 0x0, _reference_map = 0x8032fbd8, _flags = 0, _length = 414, _saved = {_resolved_reference_length = 0, _version = 0}, _lock = 0xe2d059f8}
21-05-2014
I was able to open the core in GDB and here is the stack trace: #7 <signal handler called> #8 ciEnv::get_constant_by_index_impl (this=0xe2efedb0, cpool=0xe2efe594, pool_index=-1, cache_index=6, accessor=0xe27182f8) at /HUDSON/workspace/8-2-build-linux-i586/jdk8/685/hotspot/src/share/vm/oops/oop.inline.hpp:235 #9 0xf6e15b9c in ciEnv::get_constant_by_index (this=0xe2efedb0, cpool=0xe2efe614, pool_index=-1, cache_index=6, accessor=0xe27182f8) at /HUDSON/workspace/8-2-build-linux-i586/jdk8/685/hotspot/src/share/vm/ci/ciEnv.cpp:629 #10 0xf6e3c6d8 in ciBytecodeStream::get_constant (this=0xe2efe6d4) at /HUDSON/workspace/8-2-build-linux-i586/jdk8/685/hotspot/src/share/vm/ci/ciStreams.cpp:247 #11 0xf6d89907 in GraphBuilder::load_constant (this=0xe2efe818) at /HUDSON/workspace/8-2-build-linux-i586/jdk8/685/hotspot/src/share/vm/c1/c1_GraphBuilder.cpp:866 The bci is: (gdb) p *this->_scope_data->_stream $3 = {StackObj = {<No data fields>}, _method = 0xe27182a0, _holder = 0xe27182f8, _bc_start = 0xe2719dc0 "\345\006\266\033", _was_wide = 0x0, _table_base = 0xe2c6e1c0, _start = 0xe2719db0 "\022\027\266\021", _end = 0xe2719e70 "x\236q\342\003", _pc = 0xe2719dc2 "\266\033", _bc = _ldc, _raw_bc = _fast_aldc} int cur_bci() const { return _bc_start - _start; } (gdb) p this->_scope_data->_stream->_bc_start - this->_scope_data->_stream->_start $4 = 16 which is a String: static {}; Code: 0: ldc #23 // class sun/misc/FloatingDecimal 2: invokevirtual #361 // Method java/lang/Class.desiredAssertionStatus:()Z 5: ifne 12 8: iconst_1 9: goto 13 12: iconst_0 13: putstatic #346 // Field $assertionsDisabled:Z 16: ldc #16 // String Infinity
21-05-2014
ILW=Crash, not very common, none = HLH=P2
25-04-2014
RULE nsk/stress/except/except007 Crash EXCEPTION_ACCESS_VIOLATION
11-12-2013
hs_err and replay from nsk/stress/except/except007 were added.
13-11-2013
reopend, becuase it was closed as dup. of JDK-8023824 which is closed as dup. of this.
22-10-2013
Maybe assign this one to Rickard.
19-09-2013