JDK-8226690 : SIGSEGV in MetadataOnStackClosure::do_metadata
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 13,14
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2019-06-24
  • Updated: 2021-02-17
  • Resolved: 2019-09-26
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 14
14 b17Fixed
Related Reports
Relates :  
JDK-8223585 - vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0
Relates :  
JDK-8221183 - Avoid code cache walk in MetadataOnStackMark
Relates :  
JDK-8222004 - VM crashes with: assert(!value || !is_old() || is_obsolete() || is_running_emcp()) failed: emcp methods cannot run after emcp bit is cleared
Relates :  
JDK-8231567 - minimal build failed after JDK-8226690
Relates :  
JDK-8225681 - vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due to a) MT-unsafe modification of inline cache
Description
vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java crashed:

[29.104s][trace][redefine,class,iklass,purge] purge: staticMethod((DILjava/lang/Object;)Ljava/lang/String;): prev method @2 in version @19 is alive
[29.104s][trace][redefine,class,iklass,purge] purge: regularMethod((DILjava/lang/Object;)Ljava/lang/String;): prev method @3 in version @19 is alive
[29.104s][trace][redefine,class,iklass,purge] previous version 0x0000000800e69438 is alive
[29.104s][trace][redefine,class,iklass,purge] previous methods length=7
[29.104s][trace][redefine,class,iklass,purge] purge: <init>(()V): prev method @0 in version @20 is alive
[29.104s][trace][redefine,class,iklass,purge] purge: staticMethod((DILjava/lang/Object;)Ljava/lang/String;): prev method @2 in version @20 is alive
[29.104s][trace][redefine,class,iklass,purge] previous version 0x0000000800d5a3c0 is alive
[29.104s][trace][redefine,class,iklass,purge] previous methods length=7
[29.104s][trace][redefine,class,iklass,purge] purge: <init>(()V): prev method @0 in version @21 is alive
[29.104s][trace][redefine,class,iklass,purge] purge: staticMethod((DILjava/lang/Object;)Ljava/lang/String;): prev method @2 in version @21 is alive
[29.104s][trace][redefine,class,iklass,purge] purge: regularMethod((DILjava/lang/Object;)Ljava/lang/String;): prev method @3 in version @21 is alive
[29.104s][trace][redefine,class,iklass,purge] previous version stats: live=20, deleted=2
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f9c4ee9cf3b, pid=11057, tid=11076
#
# JRE version: OpenJDK Runtime Environment (13.0) (build 13-ea+0-1370)
# Java VM: OpenJDK 64-Bit Server VM (13-ea+0-1370, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xb36f3b]  MetadataOnStackClosure::do_metadata(Metadata*)+0xb
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# testoutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_jvmti_quick/scratch/3/hs_err_pid11057.log
Compiled method (c2)   29109 4392   !   4       jdk.internal.reflect.GeneratedMethodAccessor3191::invoke (286 bytes)
 total in heap  [0x00007f9c38633710,0x00007f9c38634028] = 2328
 relocation     [0x00007f9c38633870,0x00007f9c386338e8] = 120
 main code      [0x00007f9c38633900,0x00007f9c38633c60] = 864
 stub code      [0x00007f9c38633c60,0x00007f9c38633c88] = 40
 oops           [0x00007f9c38633c88,0x00007f9c38633c98] = 16
 metadata       [0x00007f9c38633c98,0x00007f9c38633cf8] = 96
 scopes data    [0x00007f9c38633cf8,0x00007f9c38633e38] = 320
 scopes pcs     [0x00007f9c38633e38,0x00007f9c38633fb8] = 384
 dependencies   [0x00007f9c38633fb8,0x00007f9c38633fc8] = 16
 handler table  [0x00007f9c38633fc8,0x00007f9c38634008] = 64
 nul chk table  [0x00007f9c38634008,0x00007f9c38634028] = 32
Compiled method (c2)   29109 4392   !   4       jdk.internal.reflect.GeneratedMethodAccessor3191::invoke (286 bytes)
 total in heap  [0x00007f9c38633710,0x00007f9c38634028] = 2328
 relocation     [0x00007f9c38633870,0x00007f9c386338e8] = 120
 main code      [0x00007f9c38633900,0x00007f9c38633c60] = 864
 stub code      [0x00007f9c38633c60,0x00007f9c38633c88] = 40
 oops           [0x00007f9c38633c88,0x00007f9c38633c98] = 16
 metadata       [0x00007f9c38633c98,0x00007f9c38633cf8] = 96
 scopes data    [0x00007f9c38633cf8,0x00007f9c38633e38] = 320
 scopes pcs     [0x00007f9c38633e38,0x00007f9c38633fb8] = 384
 dependencies   [0x00007f9c38633fb8,0x00007f9c38633fc8] = 16
 handler table  [0x00007f9c38633fc8,0x00007f9c38634008] = 64
 nul chk table  [0x00007f9c38634008,0x00007f9c38634028] = 32
Compiled method (c2)   29109 4392   !   4       jdk.internal.reflect.GeneratedMethodAccessor3191::invoke (286 bytes)
 total in heap  [0x00007f9c38633710,0x00007f9c38634028] = 2328
 relocation     [0x00007f9c38633870,0x00007f9c386338e8] = 120
 main code      [0x00007f9c38633900,0x00007f9c38633c60] = 864
 stub code      [0x00007f9c38633c60,0x00007f9c38633c88] = 40
 oops           [0x00007f9c38633c88,0x00007f9c38633c98] = 16
 metadata       [0x00007f9c38633c98,0x00007f9c38633cf8] = 96
 scopes data    [0x00007f9c38633cf8,0x00007f9c38633e38] = 320
 scopes pcs     [0x00007f9c38633e38,0x00007f9c38633fb8] = 384
 dependencies   [0x00007f9c38633fb8,0x00007f9c38633fc8] = 16
 handler table  [0x00007f9c38633fc8,0x00007f9c38634008] = 64
 nul chk table  [0x00007f9c38634008,0x00007f9c38634028] = 32
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/d658f4379c63 User: coleenp Date: 2019-09-26 14:02:28 +0000
26-09-2019
It looks like a new nmethod can be created with an old Method* in the metadata_section that is not an evol_method dependency in between the full code cache walk in redefinition and the walk of the old_nmethods table in MetadataOnStackMark.
24-09-2019
Above comment: Yes, but not the same as the bug in the description. From some windows crash: Stack: [0x0000006cdcfc0000,0x0000006cdd0c0000], sp=0x0000006cdd0bf288, free space=1020k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xa3d27c] MetadataOnStackClosure::do_metadata+0x1c (metadataonstackmark.cpp:46) V [jvm.dll+0xa9000e] nmethod::metadata_do+0x71e (nmethod.cpp:1680) V [jvm.dll+0x46898c] CodeCache::metadata_do+0x24c (codecache.cpp:675) V [jvm.dll+0xa3d09f] MetadataOnStackMark::MetadataOnStackMark+0x11f (metadataonstackmark.cpp:69) V [jvm.dll+0x8f0343] VM_RedefineClasses::doit+0xb3 (jvmtiredefineclasses.cpp:212) V [jvm.dll+0xcd304e] VM_Operation::evaluate+0xbe (vmoperations.cpp:71) V [jvm.dll+0xcd8168] VMThread::evaluate_operation+0xb8 (vmthread.cpp:406) V [jvm.dll+0xcd8c2f] VMThread::loop+0x53f (vmthread.cpp:552) V [jvm.dll+0xcd95c8] VMThread::run+0xd8 (vmthread.cpp:305) V [jvm.dll+0xc6db22] Thread::call_run+0x192 (thread.cpp:404) V [jvm.dll+0xacba9e] thread_native_entry+0x10e (os_windows.cpp:471) C [ucrtbase.DLL+0x203ba] C [KERNEL32.DLL+0x13f2] C [ntdll.dll+0x154f4] Here: // Visit the metadata section for (Metadata** p = metadata_begin(); p < metadata_end(); p++) { if (*p == Universe::non_oop_word() || *p == NULL) continue; // skip non-oops Metadata* md = *p; f->do_metadata(md); }
24-09-2019
Is this same? # Internal Error (t:/workspace/open/src/hotspot/share/oops/method.cpp:2181), pid=44808, tid=23856 # assert(!value || !is_old() || is_obsolete() || is_running_emcp()) failed: emcp methods cannot run after emcp bit is cleared V [jvm.dll+0xacbc91] os::platform_print_native_stack+0xf1 (os_windows_x86.cpp:369) V [jvm.dll+0xcce60f] VMError::report+0xf0f (vmerror.cpp:716) V [jvm.dll+0xccfece] VMError::report_and_die+0x8ae (vmerror.cpp:1524) V [jvm.dll+0xcd05c4] VMError::report_and_die+0x64 (vmerror.cpp:1308) V [jvm.dll+0x508ba2] report_vm_error+0x102 (debug.cpp:264) V [jvm.dll+0xa5516c] Method::set_on_stack+0x9c (method.cpp:2182) V [jvm.dll+0xa8ed2e] nmethod::metadata_do+0x71e (nmethod.cpp:1680) V [jvm.dll+0x46856c] CodeCache::metadata_do+0x24c (codecache.cpp:675) V [jvm.dll+0xa3bd5f] MetadataOnStackMark::MetadataOnStackMark+0x11f (metadataonstackmark.cpp:69) V [jvm.dll+0x8ef4b3] VM_RedefineClasses::doit+0xb3 (jvmtiredefineclasses.cpp:212) V [jvm.dll+0xcd170e] VM_Operation::evaluate+0xbe (vmoperations.cpp:71) V [jvm.dll+0xcd6828] VMThread::evaluate_operation+0xb8 (vmthread.cpp:406) V [jvm.dll+0xcd72ef] VMThread::loop+0x53f (vmthread.cpp:552) V [jvm.dll+0xcd7c88] VMThread::run+0xd8 (vmthread.cpp:305) V [jvm.dll+0xc6c1e2] Thread::call_run+0x192 (thread.cpp:404) V [jvm.dll+0xaca75e] thread_native_entry+0x10e (os_windows.cpp:471)
08-08-2019
It's possible that a Method* in a static call stub was removed because MetadataOnStackMark missed it because of the nmethod table that was added for JDK-8221183, even though CompiledMethod::metadata_do *does* walk these. It could have been added between metadata stack marking. This is hard to reproduce.
31-07-2019
Stack: [0x00007f9c28215000,0x00007f9c28315000], sp=0x00007f9c283137f8, free space=1017k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xb36f3b] MetadataOnStackClosure::do_metadata(Metadata*)+0xb V [libjvm.so+0x5b2af8] CodeCache::metadata_do(MetadataClosure*)+0x188 V [libjvm.so+0xb36cb5] MetadataOnStackMark::MetadataOnStackMark(bool, bool)+0x95 V [libjvm.so+0xa01f30] VM_RedefineClasses::doit()+0x60 V [libjvm.so+0xdd8fe7] VM_Operation::evaluate()+0xe7 V [libjvm.so+0xddfefe] VMThread::evaluate_operation(VM_Operation*) [clone .constprop.68]+0xfe V [libjvm.so+0xde06ae] VMThread::loop()+0x67e V [libjvm.so+0xde0987] VMThread::run()+0x77 V [libjvm.so+0xd6e38d] Thread::call_run()+0x10d V [libjvm.so+0xbc0987] thread_native_entry(Thread*)+0xe7
02-07-2019