Bug ID: JDK-8200078 [Graal] runtime/appcds/GraalWithLimitedMetaspace.java crashes in visit_all

JDK-8200078 : [Graal] runtime/appcds/GraalWithLimitedMetaspace.java crashes in visit_all_interfaces

Type: Bug
Component: hotspot
Sub-Component: runtime
Affected Version: 11

Priority: P3
Status: Resolved
Resolution: Fixed

Submitted: 2018-03-21
Updated: 2019-06-20
Resolved: 2018-03-30

Versions (Unresolved/Resolved/Fixed)

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 11
11 b10Fixed

Related Reports

Relates :

JDK-8213250 - CDS archive creation aborts due to metaspace object allocation failure

Description

runtime/appcds/GraalWithLimitedMetaspace.java ran with Graal as JIT compiler crashes on macosx-64

#  SIGSEGV (0xb) at pc=0x0000000109f60544, pid=99904, tid=7683
#
# JRE version: Java(TM) SE Runtime Environment (11.0) (fastdebug build 11-internal+0-2018-03-21-2008371.epavlova.jdk.hs)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 11-internal+0-2018-03-21-2008371.epavlova.jdk.hs, interpreted mode, tiered, jvmci, jvmci compiler, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# V  [libjvm.dylib+0x960544]  visit_all_interfaces(Array<Klass*>*, InterfaceVisiterClosure*)+0x30
#

---------------  T H R E A D  ---------------

Current thread (0x00007fd7a8800620):  JavaThread "main" [_thread_in_vm, id=7683, stack(0x000000010ac76000,0x000000010ad76000)]

Stack: [0x000000010ac76000,0x000000010ad76000],  sp=0x000000010ad72f00,  free space=1011k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x960544]  visit_all_interfaces(Array<Klass*>*, InterfaceVisiterClosure*)+0x30
V  [libjvm.dylib+0x960656]  klassItable::compute_itable_size(Array<Klass*>*)+0x2a
V  [libjvm.dylib+0x3e4278]  ClassFileParser::post_process_parsed_stream(ClassFileStream const*, ConstantPool*, Thread*)+0xa88
V  [libjvm.dylib+0x3e2b07]  ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, Handle, InstanceKlass const*, GrowableArray<Handle>*, ClassFileParser::Publicity, Thread*)+0x5ab
V  [libjvm.dylib+0x95b86d]  KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, Handle, InstanceKlass const*, GrowableArray<Handle>*, Thread*)+0x481
V  [libjvm.dylib+0xccddc8]  SystemDictionary::resolve_from_stream(Symbol*, Handle, Handle, ClassFileStream*, Thread*)+0x136
V  [libjvm.dylib+0x80c210]  jvm_define_class_common(JNIEnv_*, char const*, _jobject*, signed char const*, int, _jobject*, char const*, Thread*)+0x49f
V  [libjvm.dylib+0x80c470]  JVM_DefineClassWithSource+0x1bc
C  [libjava.dylib+0x1675]  Java_java_lang_ClassLoader_defineClass2+0x121
j  java.lang.ClassLoader.defineClass2(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/nio/ByteBuffer;IILjava/security/ProtectionDomain;Ljava/lang/String;)Ljava/lang/Class;+0 java.base@11-internal
j  java.lang.ClassLoader.defineClass(Ljava/lang/String;Ljava/nio/ByteBuffer;Ljava/security/ProtectionDomain;)Ljava/lang/Class;+93 java.base@11-internal
j  java.security.SecureClassLoader.defineClass(Ljava/lang/String;Ljava/nio/ByteBuffer;Ljava/security/CodeSource;)Ljava/lang/Class;+8 java.base@11-internal
j  jdk.internal.loader.BuiltinClassLoader.defineClass(Ljava/lang/String;Ljdk/internal/loader/BuiltinClassLoader$LoadedModule;)Ljava/lang/Class;+127 java.base@11-internal
j  jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(Ljdk/internal/loader/BuiltinClassLoader$LoadedModule;Ljava/lang/String;)Ljava/lang/Class;+9 java.base@11-internal
j  jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Ljava/lang/String;Z)Ljava/lang/Class;+55 java.base@11-internal
j  jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Ljava/lang/String;)Ljava/lang/Class;+3 java.base@11-internal
j  jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Ljava/lang/String;Z)Ljava/lang/Class;+66 java.base@11-internal
j  jdk.internal.loader.BuiltinClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+3 java.base@11-internal
j  jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+36 java.base@11-internal
j  java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 java.base@11-internal
v  ~StubRoutines::call_stub
V  [libjvm.dylib+0x6fb160]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x478
V  [libjvm.dylib+0x6f9e99]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x2a9
V  [libjvm.dylib+0x6fa0c1]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Handle, Thread*)+0xcb
V  [libjvm.dylib+0x3e877b]  ClassListParser::load_current_class(Thread*)+0x295
V  [libjvm.dylib+0xac3b75]  MetaspaceShared::preload_classes(char const*, Thread*)+0x67
V  [libjvm.dylib+0xac39c4]  MetaspaceShared::preload_and_dump(Thread*)+0x174
V  [libjvm.dylib+0xd11b86]  Threads::create_vm(JavaVMInitArgs*, bool*)+0xa54
V  [libjvm.dylib+0x7c3664]  JNI_CreateJavaVM+0xb8
C  [java+0x4470]  JavaMain+0x113
C  [libsystem_pthread.dylib+0x393b]  _pthread_body+0xb4
C  [libsystem_pthread.dylib+0x3887]  _pthread_body+0x0
C  [libsystem_pthread.dylib+0x308d]  thread_start+0xd

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  java.lang.ClassLoader.defineClass2(Ljava/lang/ClassLoader;Ljava/lang/String;Ljava/nio/ByteBuffer;IILjava/security/ProtectionDomain;Ljava/lang/String;)Ljava/lang/Class;+0 java.base@11-internal
j  java.lang.ClassLoader.defineClass(Ljava/lang/String;Ljava/nio/ByteBuffer;Ljava/security/ProtectionDomain;)Ljava/lang/Class;+93 java.base@11-internal
j  java.security.SecureClassLoader.defineClass(Ljava/lang/String;Ljava/nio/ByteBuffer;Ljava/security/CodeSource;)Ljava/lang/Class;+8 java.base@11-internal
j  jdk.internal.loader.BuiltinClassLoader.defineClass(Ljava/lang/String;Ljdk/internal/loader/BuiltinClassLoader$LoadedModule;)Ljava/lang/Class;+127 java.base@11-internal
j  jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(Ljdk/internal/loader/BuiltinClassLoader$LoadedModule;Ljava/lang/String;)Ljava/lang/Class;+9 java.base@11-internal
j  jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Ljava/lang/String;Z)Ljava/lang/Class;+55 java.base@11-internal
j  jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Ljava/lang/String;)Ljava/lang/Class;+3 java.base@11-internal
j  jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Ljava/lang/String;Z)Ljava/lang/Class;+66 java.base@11-internal
j  jdk.internal.loader.BuiltinClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+3 java.base@11-internal
j  jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+36 java.base@11-internal
j  java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 java.base@11-internal
v  ~StubRoutines::call_stub

Comments

Ahh, excellent. Thanks.
04-04-2018
StefanK, JDK-8200466 was filed to follow-up the issue regarding _transitive_interfaces.
04-04-2018
I might be missing something here, but the above change seems to be a band-aid solution to this crash. Isn't there still a bug somewhere that could be happening in another context, that we're now only masking? If we got an OOM while the class was loaded, shouldn't ~ClassFileParser have been cautious enough when cleaning the _transitive_interface? ~ClassFileParser: // Free interfaces InstanceKlass::deallocate_interfaces(_loader_data, _super_klass, _local_interfaces, _transitive_interfaces); and: void InstanceKlass::deallocate_interfaces(ClassLoaderData* loader_data, const Klass* super_klass, Array<Klass> local_interfaces, Array<Klass> transitive_interfaces) { // Only deallocate transitive interfaces if not empty, same as super class // or same as local interfaces. See code in parseClassFile. Array<Klass> ti = transitive_interfaces; if (ti != Universe::the_empty_klass_array() && ti != local_interfaces) { // check that the interfaces don't come from super class Array<Klass> sti = (super_klass == NULL) ? NULL : InstanceKlass::cast(super_klass)->transitive_interfaces(); if (ti != sti && ti != NULL && !ti->is_shared()) { MetadataFactory::free_array<Klass*>(loader_data, ti); } } I see that Ioi has already commented that the super class is null when this happens. If that can happen, the this seems to be something that we need to fix. Also, note that the code where you think you get an OOM is not necessarily where you do get an OOM, but rather where you hit the Metaspace high-water-mark. I think this fix will cause the VM to prematurely exit if MetaspaceSize is set to a low value.
04-04-2018
How about passing _transitive_interfaces as a parameter to Klass::initialize_supers(), and then into compute_secondary_supers()? Then it can be used by InstanceKlass::compute_secondary_supers. Klass::compute_secondary_supers() needs to assert (transitive_interfaces == NULL), similar to the existing assert(num_extra_slots == 0, ...)
26-03-2018
I've tried the above suggestion on macosx. It crashes during building libjvm.dylib Stack: [0x00000001110d7000,0x00000001111d7000], sp=0x00000001111d5610, free space=1017k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0x5659dc] Array<Klass>::length() const+0xc V [libjvm.dylib+0x96a0a2] InstanceKlass::compute_secondary_supers(int)+0x32 V [libjvm.dylib+0xc1cd3d] Klass::initialize_supers(Klass, Thread)+0x5bd V [libjvm.dylib+0x5635b5] ClassFileParser::fill_instance_klass(InstanceKlass, bool, Thread)+0xa45 V [libjvm.dylib+0x5629d5] ClassFileParser::create_instance_klass(bool, Thread)+0x95 V [libjvm.dylib+0xc216a4] KlassFactory::create_from_stream(ClassFileStream, Symbol, ClassLoaderData, Handle, InstanceKlass const, GrowableArray<Handle>, Thread)+0x314 V [libjvm.dylib+0x5774ec] ClassLoader::load_class(Symbol, bool, Thread)+0x63c V [libjvm.dylib+0x104ee2d] SystemDictionary::load_instance_class(Symbol, Handle, Thread)+0x2ed V [libjvm.dylib+0x104d489] SystemDictionary::resolve_instance_class_or_null(Symbol, Handle, Handle, Thread)+0x849 V [libjvm.dylib+0x104c6bf] SystemDictionary::resolve_or_null(Symbol, Handle, Handle, Thread)+0x2cf V [libjvm.dylib+0x104c3a4] SystemDictionary::resolve_or_fail(Symbol, Handle, Handle, bool, Thread)+0x44 V [libjvm.dylib+0x104c9a2] SystemDictionary::resolve_or_fail(Symbol, bool, Thread)+0x52 V [libjvm.dylib+0x10532f3] SystemDictionary::initialize_wk_klass(SystemDictionary::WKID, int, Thread)+0x123 V [libjvm.dylib+0x10534d5] SystemDictionary::initialize_wk_klasses_until(SystemDictionary::WKID, SystemDictionary::WKID&, Thread)+0x125 V [libjvm.dylib+0xb5e51c] SystemDictionary::initialize_wk_klasses_through(SystemDictionary::WKID, SystemDictionary::WKID&, Thread)+0x2c V [libjvm.dylib+0x1052efe] SystemDictionary::initialize_preloaded_classes(Thread)+0x14e V [libjvm.dylib+0x1052d84] SystemDictionary::initialize(Thread)+0x224 V [libjvm.dylib+0x10cb118] Universe::genesis(Thread)+0x458 V [libjvm.dylib+0x10ce3a6] universe2_init()+0x26 V [libjvm.dylib+0x964eca] init_globals()+0x8a V [libjvm.dylib+0x109cc1e] Threads::create_vm(JavaVMInitArgs, bool)+0x3ae Attaching the hs_err_pid27999.log
26-03-2018
I think the fix is: void ClassFileParser::apply_parsed_class_metadata( InstanceKlass* this_klass, int java_fields_count, TRAPS) { assert(this_klass != NULL, "invariant"); _cp->set_pool_holder(this_klass); this_klass->set_constants(_cp); this_klass->set_fields(_fields, java_fields_count); this_klass->set_methods(_methods); this_klass->set_inner_classes(_inner_classes); this_klass->set_local_interfaces(_local_interfaces); - this_klass->set_transitive_interfaces(_transitive_interfaces); this_klass->set_annotations(_combined_annotations); void ClassFileParser::fill_instance_klass(InstanceKlass* ik, bool changed_by_loadhook, TRAPS) { ... ik->initialize_supers(const_cast<InstanceKlass*>(_super_klass), CHECK); + ik->set_transitive_interfaces(_transitive_interfaces); That way, we can avoid the problem inside InstanceKlass::deallocate_interfaces().
26-03-2018
Obtained using lldb on a core dump.
24-03-2018
I haven't been able to reproduce it on linux-x64 with either fastdebug or slowdebug build. On macosx-64, I could reproduce it with either fastdebug or slowdebug build. It is easier to reproduce with slowdebug build though still not every time. I've collected a call stack of the crashing thread by using lldb to analyze the core dump. See attached lldb_thread. Frame #7 is when the assert failed: (lldb) frame select 7 frame #7: 0x0000000110007b49 libjvm.dylib`InstanceKlass::cast(k=0x000000013505b0d0) at instanceKlass.hpp:1035 1032 1033 static const InstanceKlass* cast(const Klass* k) { 1034 assert(k != NULL, "k should not be null"); -> 1035 assert(k->is_instance_klass(), "cast to InstanceKlass"); 1036 return static_cast<const InstanceKlass>(k); 1037 } 1038 (lldb) print k (const Klass) $4 = { Metadata = (_valid = 0) _layout_helper = 0 _super_check_offset = 890113944 _name = 0x0000000000000000 _secondary_super_cache = 0x0000000000000000 _secondary_supers = 0xfffffffc00000001 _primary_supers = { [0] = 0x0000000000000000 [1] = 0x0000000000000000 [2] = 0x0000000000000000 [3] = 0x0000000000000000 [4] = 0x0000000000000000 [5] = 0x0000000000000000 [6] = 0x0000000000000000 [7] = 0x0000000000000009 } _java_mirror = { _obj = 0x0000000134c352c0 } _super = 0x0000000000000000 _subklass = 0x0000000000000000 _next_sibling = 0x000d000100000009 _next_link = 0x0000004b004a000a _class_loader_data = 0x0000000000000001 _modifier_flags = -1241448270 _access_flags = (_flags = 12583424) _trace_id = 249124859907 _last_biased_lock_bulk_revocation_time = 8 _prototype_header = 0x00000001351003e0 _biased_lock_revocation_count = 890532304 _vtable_len = 1 _shared_class_path_index = 7928 _shared_class_flags = 11461 _archived_mirror = 32666 }
24-03-2018
The root cause of the crash is the class java/lang/reflect/UndeclaredThrowableException fails to load due to OOM, but it shares its InstanceKlass::_transitive_interfaces with its super class, java/lang/RuntimeException, which has been successfully loaded. When the GC tries to free the UndeclaredThrowableException class, InstanceKlass::deallocate_interfaces mistakenly frees the _transitive_interfaces: (gdb) where #0 0x00007ffff61bc59c in Metabase<Metablock>::Metabase (this=0x7fffb0313b30, word_size=3) at /home/iklam/jdk/blu/open/src/hotspot/share/memory/metachunk.hpp:42 #1 0x00007ffff61b7fcc in Metablock::Metablock (this=0x7fffb0313b30, word_size=3) at /home/iklam/jdk/blu/open/src/hotspot/share/memory/metachunk.hpp:245 #2 0x00007ffff61a819f in BlockFreelist::return_block (this=0x7ffff0262450, p=0x7fffb0313b30, word_size=3) at /home/iklam/jdk/blu/open/src/hotspot/share/memory/metaspace.cpp:1464 #3 0x00007ffff61b0f71 in SpaceManager::deallocate (this=0x7ffff0208730, p=0x7fffb0313b30, word_size=2) at /home/iklam/jdk/blu/open/src/hotspot/share/memory/metaspace.cpp:3583 #4 0x00007ffff61b5a4b in Metaspace::deallocate (this=0x7ffff02086e0, ptr=0x7fffb0313b30, word_size=2, is_class=false) at /home/iklam/jdk/blu/open/src/hotspot/share/memory/metaspace.cpp:4837 #5 0x00007ffff5a21f37 in MetadataFactory::free_array<Klass> (loader_data=0x7ffff0203150, data=0x7fffb0313b30) at /home/iklam/jdk/blu/open/src/hotspot/share/memory/metadataFactory.hpp:57 #6 0x00007ffff5d529cd in InstanceKlass::deallocate_interfaces (loader_data=0x7ffff0203150, super_klass=0x0, local_interfaces=0x7fffb02eb3f8, transitive_interfaces=0x7fffb0313b30) at /home/iklam/jdk/blu/open/src/hotspot/share/oops/instanceKlass.cpp:258 #7 0x00007ffff5d52d91 in InstanceKlass::deallocate_contents (this=0x8c00dcf18, loader_data=0x7ffff0203150) at /home/iklam/jdk/blu/open/src/hotspot/share/oops/instanceKlass.cpp:332 #8 0x00007ffff58e431c in MetadataFactory::free_metadata<InstanceKlass> (loader_data=0x7ffff0203150, md=0x8c00dcf18) at /home/iklam/jdk/blu/open/src/hotspot/share/memory/metadataFactory.hpp:70 #9 0x00007ffff58df219 in ClassLoaderData::free_deallocate_list (this=0x7ffff0203150) at /home/iklam/jdk/blu/open/src/hotspot/share/classfile/classLoaderData.cpp:810 #10 0x00007ffff58e0f57 in ClassLoaderDataGraph::do_unloading (is_alive_closure=0x7fffb01fe8f0, clean_previous_versions=true) at /home/iklam/jdk/blu/open/src/hotspot/share/classfile/classLoaderData.cpp:1231 #11 0x00007ffff649d8dd in SystemDictionary::do_unloading (is_alive=0x7fffb01fe8f0, gc_timer=0x7fffb01fe688, do_cleaning=true) at /home/iklam/jdk/blu/open/src/hotspot/share/classfile/systemDictionary.cpp:1857 #12 0x00007ffff5be69bb in G1FullCollector::phase1_mark_live_objects (this=0x7fffb01fe600) at /home/iklam/jdk/blu/open/src/hotspot/share/gc/g1/g1FullCollector.cpp:192 #13 0x00007ffff5be66c9 in G1FullCollector::collect (this=0x7fffb01fe600) at /home/iklam/jdk/blu/open/src/hotspot/share/gc/g1/g1FullCollector.cpp:135 #14 0x00007ffff5ba93aa in G1CollectedHeap::do_full_collection (this=0x7ffff002bfe0, explicit_gc=true, clear_all_soft_refs=false) at /home/iklam/jdk/blu/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:1171 #15 0x00007ffff5ba9431 in G1CollectedHeap::do_full_collection (this=0x7ffff002bfe0, clear_all_soft_refs=false) at /home/iklam/jdk/blu/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:1183 #16 0x00007ffff59484fc in CollectedHeap::collect_as_vm_thread (this=0x7ffff002bfe0, cause=GCCause::_metadata_GC_threshold) at /home/iklam/jdk/blu/open/src/hotspot/share/gc/shared/collectedHeap.cpp:227 #17 0x00007ffff657e2b7 in VM_CollectForMetadataAllocation::doit (this=0x7ffff7fc5bf0) at /home/iklam/jdk/blu/open/src/hotspot/share/gc/shared/vmGCOperations.cpp:251 #18 0x00007ffff65c41b6 in VM_Operation::evaluate (this=0x7ffff7fc5bf0) at /home/iklam/jdk/blu/open/src/hotspot/share/runtime/vm_operations.cpp:67 #19 0x00007ffff65c0da7 in VMThread::evaluate_operation (this=0x7ffff03da040, op=0x7ffff7fc5bf0) at /home/iklam/jdk/blu/open/src/hotspot/share/runtime/vmThread.cpp:353 #20 0x00007ffff65c1559 in VMThread::loop (this=0x7ffff03da040) at /home/iklam/jdk/blu/open/src/hotspot/share/runtime/vmThread.cpp:494 #21 0x00007ffff65c0aff in VMThread::run (this=0x7ffff03da040) at /home/iklam/jdk/blu/open/src/hotspot/share/runtime/vmThread.cpp:266 #22 0x00007ffff62a0802 in thread_native_entry (thread=0x7ffff03da040) at /home/iklam/jdk/blu/open/src/hotspot/os/linux/os_linux.cpp:699 #23 0x00007ffff79a76fa in start_thread (arg=0x7fffb01ff700) at pthread_create.c:333 #24 0x00007ffff72cab5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 void InstanceKlass::deallocate_interfaces(...) { ... // check that the interfaces don't come from super class Array<Klass> sti = (super_klass == NULL) ? NULL : InstanceKlass::cast(super_klass)->transitive_interfaces(); if (ti != sti && ti != NULL && !ti->is_shared()) { MetadataFactory::free_array<Klass>(loader_data, ti); <<<<< HERE } (gdb) p super_klass $14 = (const Klass ) 0x0 However, UndeclaredThrowableException has only been partially parsed, so its _super field has not yet been initialized. Hence, the above code thinks the transitive_interfaces is not shared and can be freed.
22-03-2018
This seems to be a bug in the class file parser code. It should fail gracefully when OOM happens, but apparently visit_all_interfaces has dereferenced a bad pointer: :visit_all_interfaces(Array<Klass>, InterfaceVisiterClosure): 960ad4: 55 pushq %rbp 960ad5: 48 89 e5 movq %rsp, %rbp 960ad8: 41 57 pushq %r15 960ada: 41 56 pushq %r14 960adc: 41 55 pushq %r13 960ade: 41 54 pushq %r12 960ae0: 53 pushq %rbx 960ae1: 48 83 ec 18 subq $24, %rsp 960ae5: 48 89 75 c0 movq %rsi, -64(%rbp) 960ae9: 48 89 7d c8 movq %rdi, -56(%rbp) 960aed: 83 3f 00 cmpl $0, (%rdi) 960af0: 0f 8e e6 00 00 00 jle 230 <visit_all_interfaces(Array<Klass>, InterfaceVisiterClosure)+0x108> 960af6: 45 31 e4 xorl %r12d, %r12d 960af9: 44 89 e6 movl %r12d, %esi 960afc: e8 f7 4b a8 ff callq -5747721 <Array<Klass>::at(int) const> 960b01: 48 89 c3 movq %rax, %rbx >>960b04: f6 83 a5 00 00 00 02 testb $2, 165(%rbx) <<<<< CRASH 960b0b: 75 3d jne 61 <visit_all_interfaces(Array<Klass>, InterfaceVisiterClosure)+0x76> 960b0d: e8 ad fe b6 ff callq -4784467 <is_executing_unit_tests()> 960b12: 84 c0 testb %al, %al 960b14: 74 0e je 14 <visit_all_interfaces(Array<Klass>, InterfaceVisiterClosure)+0x50> 960b16: 31 c0 xorl %eax, %eax 960b18: 48 8d 3d 81 92 4b 00 leaq 4952705(%rip), %rdi 960b1f: e8 aa fe b6 ff callq -4784470 <report_assert_msg(char const, ...)> 960b24: be 4d 05 00 00 movl $1357, %esi Registers: RAX=0x030007011300fe1a, RBX=0x030007011300fe1a, RCX=0x000000010b547ec8, RDX=0x00000008c0030d00 RSP=0x000000010b547f00, RBP=0x000000010b547f40, RSI=0x0000000000000000, RDI=0x00000001317898e8 R8 =0x0000000000000000, R9 =0x000000013151b448, R10=0x00007fc19b1bca68, R11=0x0000000000000001 R12=0x0000000000000000, R13=0x000000010b5481b8, R14=0x000000010af490a0, R15=0x00007fc19b173160 void visit_all_interfaces(Array<Klass> transitive_intf, InterfaceVisiterClosure blk) { // Handle array argument for(int i = 0; i < transitive_intf->length(); i++) { Klass intf = transitive_intf->at(i); assert(intf->is_interface(), "sanity check"); <<< CRASH on intf->interface(); We can see that RBX is returned by transitive_intf->at(i); At this point, i is in R12 which is 0. So transitive_intf->at(0) has returned 0x030007011300fe1a for "intf", which is a bad pointer. This intf->interface() crashes. The question is -- why would transitive_intf->at(0) contain a bad pointer, when we get an OOM in the metaspace. *** I can reliably reproduce the crash on Linux/x64 using the slow debug build.
22-03-2018
Steps to reproduce: > jtreg -vt -jdk:JDK-HS_fastdebug -vmoptions:-XX:MaxRAMPercentage=12 -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal runtime/appcds/GraalWithLimitedMetaspace.java The issue seems to be intermittent, but I was able to reproduce it on 2nd iteration. No failure on linux-x64 observed.
21-03-2018