JDK-8220761 : compiler/loopstripmining/CheckLoopStripMining.java crashed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 13
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • Submitted: 2019-03-17
  • Updated: 2019-10-17
  • Resolved: 2019-10-17
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
14Resolved
Related Reports
Relates :  
Description
----------System.out:(31/2011)----------
CompileCommand: compileonly CheckLoopStripMining.test_loop
[9.200s][warning][safepoint] 
[9.200s][warning][safepoint] # SafepointSynchronize::begin: Timeout detected:
[9.200s][warning][safepoint] # SafepointSynchronize::begin: Timed out while spinning to reach a safepoint.
[9.200s][warning][safepoint] # SafepointSynchronize::begin: Threads which did not reach the safepoint:
[9.200s][warning][safepoint] # "MainThread" #11 prio=5 os_prio=64 cpu=7758.34ms elapsed=8.68s tid=0x00000001007b6000 nid=0x11 runnable  [0xffffffff60bfb000]
[9.200s][warning][safepoint]    java.lang.Thread.State: RUNNABLE
[9.200s][warning][safepoint] Thread: 0x00000001007b6000  [0x11] State: _running _at_poll_safepoint 0
[9.200s][warning][safepoint]    JavaThread state: _thread_in_vm
[9.200s][warning][safepoint] 
[9.200s][warning][safepoint] # SafepointSynchronize::begin: (End of list)
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0xffffffff7de17384, pid=20252, tid=17
#
# JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-internal+0-jdk13-jdk.627)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-internal+0-jdk13-jdk.627, compiled mode, sharing, compressed oops, g1 gc, solaris-sparc)
# Problematic frame:
# V  [libjvm.so+0x1e17384]  metaspace::Metachunk::Metachunk(metaspace::ChunkIndex,bool,unsigned long,metaspace::VirtualSpaceNode*)+0x4
#
# Core dump will be written. Default location: /opt/mach5/mesos/work_dir/87c26fc9-953d-42a3-8912-a6c08a4f8adb/testOutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_not_fast_compiler/scratch/4/core or core.20252
#
# An error report file with more information is saved as:
# /opt/mach5/mesos/work_dir/87c26fc9-953d-42a3-8912-a6c08a4f8adb/testOutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_not_fast_compiler/scratch/4/hs_err_pid20252.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 17
Dumping core ...


Stack: [0xffffffff60b00000,0xffffffff60c00000],  sp=0xffffffff60bf9d70,  free space=999k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1e17384]  metaspace::Metachunk::Metachunk(metaspace::ChunkIndex,bool,unsigned long,metaspace::VirtualSpaceNode*)+0x4
V  [libjvm.so+0x2324b3c]  metaspace::Metachunk*metaspace::VirtualSpaceNode::take_from_committed(unsigned long)+0x3bc
V  [libjvm.so+0x2322e10]  metaspace::Metachunk*metaspace::VirtualSpaceList::get_new_chunk(unsigned long,unsigned long)+0x20
V  [libjvm.so+0x1e1dbc4]  void ClassLoaderMetaspace::initialize_first_chunk(Metaspace::MetaspaceType,Metaspace::MetadataType)+0x24
V  [libjvm.so+0x1e1ded4]  void ClassLoaderMetaspace::initialize(Mutex*,Metaspace::MetaspaceType)+0x134
V  [libjvm.so+0x12a1874]  ClassLoaderMetaspace*ClassLoaderData::metaspace_non_null()+0x264
V  [libjvm.so+0x1e1ce9c]  MetaWordImpl**Metaspace::allocate(ClassLoaderData*,unsigned long,MetaspaceObj::Type,Thread*)+0x10c
V  [libjvm.so+0x140d134]  Array<__type_0>*MetadataFactory::new_array<unsigned char>(ClassLoaderData*,int,__type_0,Thread*)+0x34
V  [libjvm.so+0x140d478]  ConstantPool*ConstantPool::allocate(ClassLoaderData*,int,Thread*)+0x18
V  [libjvm.so+0x1289b64]  void ClassFileParser::parse_stream(const ClassFileStream*const,Thread*)+0x674
V  [libjvm.so+0x1288f40]  ClassFileParser::ClassFileParser #Nvariant 1(ClassFileStream*,Symbol*,ClassLoaderData*,Handle,const InstanceKlass*,GrowableArray<Handle>*,ClassFileParser::Publicity,Thread*)+0x6d0
V  [libjvm.so+0x1c95ad0]  InstanceKlass*KlassFactory::create_from_stream(ClassFileStream*,Symbol*,ClassLoaderData*,Handle,const InstanceKlass*,GrowableArray<Handle>*,Thread*)+0x520
V  [libjvm.so+0x21e9c94]  InstanceKlass*SystemDictionary::parse_stream(Symbol*,Handle,Handle,ClassFileStream*,const InstanceKlass*,GrowableArray<Handle>*,Thread*)+0x284
V  [libjvm.so+0x22b86a0]  InstanceKlass*Unsafe_DefineAnonymousClass_impl(JNIEnv_*,_jclass*,_jbyteArray*,_jobjectArray*,unsigned char**,Thread*)+0xc50
V  [libjvm.so+0x22b8924]  Unsafe_DefineAnonymousClass0+0x1d4
j  jdk.internal.misc.Unsafe.defineAnonymousClass0(Ljava/lang/Class;[B[Ljava/lang/Object;)Ljava/lang/Class;+-5083592 java.base@13-internal
[...]

Comments
This is doing what we want it to do: // To debug the long safepoint, specify both AbortVMOnSafepointTimeout & // ShowMessageBoxOnError. if (AbortVMOnSafepointTimeout) { // Send the blocking thread a signal to terminate and write an error file. for (JavaThreadIteratorWithHandle jtiwh; JavaThread *cur_thread = jtiwh.next(); ) { if (cur_thread->safepoint_state()->is_running()) { if (!os::signal_thread(cur_thread, SIGILL, "blocking a safepoint")) { break; // Could not send signal. Report fatal error. } // Give cur_thread a chance to report the error and terminate the VM. os::naked_sleep(3000); } } fatal("Safepoint sync time longer than " INTX_FORMAT "ms detected when executing %s.", SafepointTimeoutDelay, VMThread::vm_operation()->name()); } The VM thread will send SIGILL to the thread that won't come to a safepoint. The example I have on macosx is swapped out in the OS doing a stat call: frame #9: 0x00007fff7b422f5a libsystem_platform.dylib`_sigtramp + 26 frame #10: 0x00007fff7b26651b libsystem_kernel.dylib`stat$INODE64 + 11 * frame #11: 0x00000001091f3fd9 libjvm.dylib`AttachListener::vm_start() + 137 The linked bug is that the safepoint timeout is too short in this test. This failure is a symptom of that bug. The stack trace in the description might be a long path between safepoint checks but it's hard to tell without further testing and a reproducer. Closing as CNR again.
17-10-2019

It looks like the safepoint timeout may have put another thread in a state where it crashes. There are a few instances of this on solaris-sparcv9 in different places. The artifacts for all of these seem to be gone. Closing as CNR.
17-10-2019

This does not look like a compiler issue. Moving to hotspot/runtime.
18-03-2019