JDK-8042660 : vm/mlvm/anonloader/stress/byteMutation failed with: assert(index >=0 && index < _length) failed: symbol index overflow
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8u101,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-05-07
  • Updated: 2016-10-13
  • Resolved: 2015-12-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
8u112Fixed 9 b103Fixed
Related Reports
Duplicate :  
JDK-8049026 - assert(has_cp_cache(i)) failed: oob with vm/mlvm/anonloader/stress/byteMutation
Relates :  
JDK-8146130 - Unquarantine test vm/mlvm/anonloader/stress/byteMutation
Relates :  
JDK-8043680 - RFE - add debugging info for ByteMutation and other MLVM vm testbase tests
Description
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/193222.vkozlov/s/src/share/vm/oops/symbol.hpp:165), pid=13465, tid=140611594729216
#  assert(index >=0 && index < _length) failed: symbol index overflow
#
# JRE version: Java(TM) SE Runtime Environment (9.0-b11) (build 1.9.0-ea-fastdebug-b11)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-201405061932.vkozlov.8042309-fastdebug compiled mode linux-amd64 compressed oops)
Comments
The issue is not reproducible with 7u.
15-07-2016
Deferral Request: Since it is not a regression, I see no reason this has to be fixed in July. I have opened a backport to the October release, suggest to defer it to then
10-06-2016
Boris, could you verify that this is not a recent regression? In that case, I agree that it should be fixed, but it is not critical for July. I opened a backport on the October release.
09-06-2016
The assert in ClassFileParser::parse_constant_pool()'s call to byte_at() could occur here if sig is a symbol of length 0: case JVM_CONSTANT_NameAndType: { if (_need_verify && _major_version >= JAVA_7_VERSION) { int sig_index = cp->signature_ref_index_at(index); int name_index = cp->name_ref_index_at(index); Symbol* name = cp->symbol_at(name_index); Symbol* sig = cp->symbol_at(sig_index); if (sig->byte_at(0) == JVM_SIGNATURE_FUNC)
15-12-2015
Similar but not identical failure: # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000000575e5d04, pid=17400, tid=16060 # # JRE version: Java(TM) SE Runtime Environment (9.0-b20) (build 1.9.0-ea-fastdebug-b20) # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-fastdebug-internal-201407030703.anoll.8022968 compiled mode windows-amd64 compressed oops) # Problematic frame: # V [jvm.dll+0x105d04] Bytecode_lookupswitch::verify+0x144 V [jvm.dll+0x105d04] Bytecode_lookupswitch::verify+0x144;; ?verify@Bytecode_lookupswitch@@QEBAXXZ+0x144 V [jvm.dll+0x12a7d2] Rewriter::scan_method+0x1d2;; ?scan_method@Rewriter@@AEAAXPEAVMethod@@_NPEA_N@Z+0x1d2 V [jvm.dll+0x12b34e] Rewriter::rewrite_bytecodes+0x10e;; ?rewrite_bytecodes@Rewriter@@AEAAXPEAVThread@@@Z+0x10e V [jvm.dll+0x12b746] Rewriter::Rewriter+0x236;; ??0Rewriter@@AEAA@VinstanceKlassHandle@@VconstantPoolHandle@@PEAV?$Array@PEAVMethod@@@@PEAVThread@@@Z+0x236 V [jvm.dll+0x12baa0] Rewriter::rewrite+0x80;; ?rewrite@Rewriter@@SAXVinstanceKlassHandle@@PEAVThread@@@Z+0x80 V [jvm.dll+0x1966df] InstanceKlass::rewrite_class+0x10f;; ?rewrite_class@InstanceKlass@@QEAAXPEAVThread@@@Z+0x10f V [jvm.dll+0x1a9f59] InstanceKlass::link_class_impl+0x489;; ?link_class_impl@InstanceKlass@@CA_NVinstanceKlassHandle@@_NPEAVThread@@@Z+0x489 V [jvm.dll+0x1adc6d] InstanceKlass::link_class+0xed;; ?link_class@InstanceKlass@@QEAAXPEAVThread@@@Z+0xed V [jvm.dll+0xb7485] SystemDictionary::parse_stream+0x295;; ?parse_stream@SystemDictionary@@SAPEAVKlass@@PEAVSymbol@@VHandle@@1PEAVClassFileStream@@VKlassHandle@@PEAV?$GrowableArray@VHandle@@@@PEAVThread@@@Z+0x295 V [jvm.dll+0x2cfbde] Unsafe_DefineAnonymousClass_impl+0x49e;; ?Unsafe_DefineAnonymousClass_impl@@YA?AVinstanceKlassHandle@@PEAUJNIEnv_@@PEAV_jclass@@PEAV_jbyteArray@@PEAV_jobjectArray@@PEAPEAVHeapWord@@PEAVThread@@@Z+0x49e V [jvm.dll+0x2cfe0d] Unsafe_DefineAnonymousClass+0x17d;; Unsafe_DefineAnonymousClass+0x17d
09-07-2014
The top of the traceback in the hs error log is: V [libjvm.so+0x1297620] void VMError::report_and_die()+0x598;; __1cHVMErrorOreport_and_die6M_v_+0x598 V [libjvm.so+0x73e840] void report_vm_error(const char*,int,const char*,const char*)+0x78;; __1cPreport_vm_error6Fpkci11_v_+0x78 V [libjvm.so+0x59f514] int Symbol::byte_at(int)const+0x54;; __1cGSymbolHbyte_at6kMi_i_+0x54 V [libjvm.so+0x60df00] constantPoolHandle ClassFileParser::parse_constant_pool(Thread*)+0x1bf8;; __1cPClassFileParserTparse_constant_pool6MpnGThread__nSconstantPoolHandle__+0x1bf8 .... But all the direct calls to Symbol::byte_at() from parse_constant_pool() are byte_at(0). Can symbols get created with zero length?
07-05-2014
It also failed on solaris-sparc.
07-05-2014