JDK-8198913 : Secondary failure in os::print_register_info during error reporting
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS: linux
  • Submitted: 2018-03-01
  • Updated: 2018-09-12
  • Resolved: 2018-09-12
Related Reports
Duplicate :  
JDK-8191798 - redo nested ThreadsListHandle to drop Threads_lock
Relates :  
JDK-8191798 - redo nested ThreadsListHandle to drop Threads_lock
Description
This can be easily reproduced on Linux: 
-XX:+CrashGCForDumpingJavaThread -version

it failed in assertion:

#6  0x00007fa6f5b1026a in OopStorage::find_block_or_null (ptr=0x0, this=0x7fa6ec241d90)
    at /home/zgu/workspace/jdk10-hs/src/hotspot/share/gc/shared/oopStorage.cpp:402
402	  assert(ptr != NULL, "precondition");
Comments
[~zgu] Thanks!
12-09-2018
Yes, I agree.
12-09-2018
[~zgu] - do you agree that this bug is fixed? If so, I plan to close it as a duplicate of JDK-8191798.
11-09-2018
I believe that this issue is resolved by the fix for the following bug: JDK-8191798 redo nested ThreadsListHandle to drop Threads_lock I ran current jdk/jdk bits on my Linux machine with the following options: -XX:+CrashGCForDumpingJavaThread -version and I no longer see the crash in the Thread-SMR code: $ build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java -XX:+CrashGCForDumpingJavaThread -version java version "12-internal" 2019-03-19 Java(TM) SE Runtime Environment 19.3 (fastdebug build 12-internal+0-2018-09-10-0303185.dcubed.jdkbaseline) Java HotSpot(TM) 64-Bit Server VM 19.3 (fastdebug build 12-internal+0-2018-09-10-0303185.dcubed.jdkbaseline, mixed mode) # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f5592be577c, pid=1831, tid=1847 # # JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug build 12-internal+0-2018-09-10-0303185.dcubed.jdkbaseline) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 12-internal+0-2018-09-10-0303185.dcubed.jdkbaseline, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0xc9a77c] frame::oops_do_internal(OopClosure*, CodeBlobClosure*, RegisterMap*, bool)+0x2c # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /work/shared/mirrors/src_clones/jdk/jdk_baseline/core.1831) # # An error report file with more information is saved as: # /work/shared/mirrors/src_clones/jdk/jdk_baseline/hs_err_pid1831.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Current thread is 1847 Dumping core ... Aborted (core dumped) Here's a snippet of the stack trace: --------------- T H R E A D --------------- Current thread (0x00007f558c425000): VMThread "VM Thread" [stack: 0x00007f5541e67000,0x00007f5541f67000] [id=1847] Stack: [0x00007f5541e67000,0x00007f5541f67000], sp=0x00007f5541f64820, free space=1014k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xc9a77c] frame::oops_do_internal(OopClosure*, CodeBlobClosure*, RegisterMap*, bool)+0x2c V [libjvm.so+0x17e9297] JavaThread::oops_do(OopClosure*, CodeBlobClosure*)+0x1d7 V [libjvm.so+0x17f5b8a] Threads::verify()+0x5a V [libjvm.so+0x18466f2] Universe::verify(VerifyOption, char const*)+0x1e2 V [libjvm.so+0x190513c] VMThread::run()+0x1bc V [libjvm.so+0x14e84a0] thread_native_entry(Thread*)+0x100 JavaThread 0x00007f558c443800 (nid = 1848) was being processed Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j java.lang.ref.Reference.waitForReferencePendingList()V+0 java.base@12-internal j java.lang.ref.Reference.processPendingReferences()V+0 java.base@12-internal j java.lang.ref.Reference$ReferenceHandler.run()V+0 java.base@12-internal v ~StubRoutines::call_stub Please see the attached hs_err_pid1831.log.
11-09-2018
As has been warned in the past, the more stuff we cram into error reporting the more chance of hitting secondary failures. Trying to obtain a stable threadslist via SMR seems like an unlikely thing to achieve successfully from an error reporting context, when it requires going to a safepoint in the worst case (IIRC).
03-03-2018
Also see assertion failure in threadSMR.cpp #5 0x00007f8899b5ffa1 in report_fatal (file=file@entry=0x7f889ae331d8 "/home/zgu/workspace/shenandoah-jdk10/src/hotspot/share/runtime/thread.cpp", line=line@entry=970, detail_fmt=detail_fmt@entry=0x7f889ae352e3 "LEAF method calling lock?") at /home/zgu/workspace/shenandoah-jdk10/src/hotspot/share/utilities/debug.cpp:228 #6 0x00007f889ab5a6aa in Thread::check_for_valid_safepoint_state (this=this@entry=0x7f889405f000, potential_vm_operation=potential_vm_operation@entry=false) at /home/zgu/workspace/shenandoah-jdk10/src/hotspot/share/runtime/thread.cpp:970 #7 0x00007f889ab74482 in ThreadsSMRSupport::acquire_stable_list (is_ThreadsListSetter=false, self=0x7f889405f000) at /home/zgu/workspace/shenandoah-jdk10/src/hotspot/share/runtime/threadSMR.cpp:555 #8 ThreadsListHandle::ThreadsListHandle (this=0x7f889c2a2a18, self=0x7f889405f000) at /home/zgu/workspace/shenandoah-jdk10/src/hotspot/share/runtime/threadSMR.cpp:467 #9 0x00007f889a3b7b72 in JavaThreadIteratorWithHandle::JavaThreadIteratorWithHandle (this=0x7f889c2a2a10) at /home/zgu/workspace/shenandoah-jdk10/src/hotspot/share/runtime/threadSMR.hpp:302 #10 os::print_location (st=st@entry=0x7f889b492060 <VMError::log>, x=140224642455846, verbose=verbose@entry=false) at /home/zgu/workspace/shenandoah-jdk10/src/hotspot/share/runtime/os.cpp:1096 #11 0x00007f889a3d30e5 in os::print_register_info (st=0x7f889b492060 <VMError::log>, context=0x7f889c2a2e80) (gdb) f 7 #7 0x00007f889ab74482 in ThreadsSMRSupport::acquire_stable_list (is_ThreadsListSetter=false, self=0x7f889405f000) at /home/zgu/workspace/shenandoah-jdk10/src/hotspot/share/runtime/threadSMR.cpp:555 555 debug_only(if (!is_ThreadsListSetter && StrictSafepointChecks) self->check_for_valid_safepoint_state(/* potential_vm_operation */ false);)
02-03-2018