I spotted the following:
Stack: [0x00007fc0da919000,0x00007fc0daa1a000], sp=0x00007fc0daa18180, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xf55024] HandleArea::allocate_handle(oop)+0x214 (handles.cpp:40)
V [libjvm.so+0x1416adb] klassVtable::check_constraints(GrowableArray<InstanceKlass*>*, JavaThread*)+0x5eb (handles.inline.hpp:42)
V [libjvm.so+0x1417981] klassVtable::initialize_vtable_and_check_constraints(JavaThread*)+0x1a1 (klassVtable.cpp:620)
V [libjvm.so+0x1011257] InstanceKlass::link_class_impl(JavaThread*)+0x3d7 (instanceKlass.cpp:917)
V [libjvm.so+0x1620c47] MetaspaceShared::try_link_class(JavaThread*, InstanceKlass*)+0xc7 (metaspaceShared.cpp:832)
V [libjvm.so+0x1621797] MetaspaceShared::link_shared_classes(bool, JavaThread*)+0x2e7 (metaspaceShared.cpp:620)
V [libjvm.so+0xd01988] DynamicArchive::dump_at_exit(JavaThread*, char const*)+0x318 (dynamicArchive.cpp:391)
V [libjvm.so+0x10651d6] before_exit(JavaThread*, bool)+0x86 (java.cpp:445)
V [libjvm.so+0x1ac8798] Threads::destroy_vm()+0x1b8 (threads.cpp:1085)
V [libjvm.so+0x118c1ad] jni_DestroyJavaVM+0xad (jni.cpp:3735)
C [libjli.so+0x3d42] JavaMain+0x2c2 (java.c:555)
C [libjli.so+0x7a29] ThreadJavaMain+0x9 (java_md.c:650)
The second line:
V [libjvm.so+0x1416adb] klassVtable::check_constraints(GrowableArray<InstanceKlass*>*, JavaThread*)+0x5eb (handles.inline.hpp:42)
is incorrectly listed as being from handles.inline.hpp when it is actually in klassVtable.cpp
Stack: [0x00007fc0da919000,0x00007fc0daa1a000], sp=0x00007fc0daa18180, free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xf55024] HandleArea::allocate_handle(oop)+0x214 (handles.cpp:40)
V [libjvm.so+0x1416adb] klassVtable::check_constraints(GrowableArray<InstanceKlass*>*, JavaThread*)+0x5eb (handles.inline.hpp:42)
V [libjvm.so+0x1417981] klassVtable::initialize_vtable_and_check_constraints(JavaThread*)+0x1a1 (klassVtable.cpp:620)
V [libjvm.so+0x1011257] InstanceKlass::link_class_impl(JavaThread*)+0x3d7 (instanceKlass.cpp:917)
V [libjvm.so+0x1620c47] MetaspaceShared::try_link_class(JavaThread*, InstanceKlass*)+0xc7 (metaspaceShared.cpp:832)
V [libjvm.so+0x1621797] MetaspaceShared::link_shared_classes(bool, JavaThread*)+0x2e7 (metaspaceShared.cpp:620)
V [libjvm.so+0xd01988] DynamicArchive::dump_at_exit(JavaThread*, char const*)+0x318 (dynamicArchive.cpp:391)
V [libjvm.so+0x10651d6] before_exit(JavaThread*, bool)+0x86 (java.cpp:445)
V [libjvm.so+0x1ac8798] Threads::destroy_vm()+0x1b8 (threads.cpp:1085)
V [libjvm.so+0x118c1ad] jni_DestroyJavaVM+0xad (jni.cpp:3735)
C [libjli.so+0x3d42] JavaMain+0x2c2 (java.c:555)
C [libjli.so+0x7a29] ThreadJavaMain+0x9 (java_md.c:650)
The second line:
V [libjvm.so+0x1416adb] klassVtable::check_constraints(GrowableArray<InstanceKlass*>*, JavaThread*)+0x5eb (handles.inline.hpp:42)
is incorrectly listed as being from handles.inline.hpp when it is actually in klassVtable.cpp
- relates to
-
JDK-8305489 runtime/ErrorHandling/TestDwarf.java fails in some Linux configurations after JDK-8303805
- Resolved
-
JDK-8242181 [Linux] Show source information when printing native stack traces in hs_err files
- Resolved