JDK-8217908 : assetion fails in jfrTraceId::use METHOD_AND_CLASS_USED_THIS_EPOCH
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 13
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2019-01-28
  • Updated: 2019-10-31
  • Resolved: 2019-10-31
Related Reports
Duplicate :  
Relates :  
Description
Test: jdk/jfr/startupargs/TestStartRecording.java
Observer on: MAC OSX so far, only once so far
Error type: assert/crash

Details:
#  assert(((((klass)->trace_id() & (JfrTraceIdEpoch::method_and_class_in_use_this_epoch_bits())) == (JfrTraceIdEpoch::method_and_class_in_use_this_epoch_bits())) != 0)) failed: invariant
#
# JRE version: Java(TM) SE Runtime Environment (13.0) (fastdebug build 13-internal+0-jdk13-jdk.241)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 13-internal+0-jdk13-jdk.241, mixed mode, sharing, tiered, compressed oops, g1 gc, bsd-amd64)


===================================
The file and line info point to: 
   jfrTraceId.inline.hpp:   assert(METHOD_AND_CLASS_USED_THIS_EPOCH(klass), "invariant");


inline traceid JfrTraceId::use(const Method* method, bool leakp /* false */) {
  assert(method != NULL, "invariant");
  SET_METHOD_FLAG_USED_THIS_EPOCH(method);
  const Klass* const klass = method->method_holder();
  assert(klass != NULL, "invariant");
  if (leakp) {
    SET_LEAKP_USED_THIS_EPOCH(klass);
    assert(LEAKP_USED_THIS_EPOCH(klass), "invariant");
  }
  SET_METHOD_AND_CLASS_USED_THIS_EPOCH(klass);
  assert(METHOD_AND_CLASS_USED_THIS_EPOCH(klass), "invariant");       <<<============
  return (METHOD_ID(klass, method));
}

Comments
Only bugs associated with a changeset should be closed as "fixed". This bug has been closed as a duplicate of JDK-8226511 .
31-10-2019

The situation could occur if there is an emergency dump in progress. Part of the emergency dump would shift the epoch outside of a safepoint. This could lead to the situation described. As of JDK-8226511, the logic for doing the emergency dump will instead keep the current epoch and reuse the logic for a regular flush, so this situation should not occur post JDK-8226511. https://hg.openjdk.java.net/jdk/jdk/rev/c16ac7a2eba4#l56.791
31-10-2019

Call Stack: --------------- T H R E A D --------------- Current thread (0x00007ff5b4047800): Thread [stack: 0x00007000090cd000,0x00007000091cd000] [id=39943] _threads_hazard_ptr=0x00007ff5b5702520, _nested_threads_hazard_ptr_cnt=0 Stack: [0x00007000090cd000,0x00007000091cd000], sp=0x00007000091cb310, free space=1016k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0xc1e057] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x5fb V [libjvm.dylib+0xc1e69d] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x47 V [libjvm.dylib+0x431d1f] report_vm_error(char const*, int, char const*, char const*, ...)+0xcc V [libjvm.dylib+0x24c9d0] JfrTraceId::use(Method const*, bool)+0x19c V [libjvm.dylib+0x6893df] JfrStackTrace::record_thread(JavaThread&, frame&)+0x9f V [libjvm.dylib+0x6980d7] JfrNativeSamplerCallback::call()+0xcf V [libjvm.dylib+0x69831d] JfrThreadSampleClosure::sample_thread_in_native(JavaThread*, JfrStackFrame*, unsigned int)+0x97 V [libjvm.dylib+0x69880a] JfrThreadSampleClosure::do_sample_thread(JavaThread*, JfrStackFrame*, unsigned int, JfrSampleType)+0x15a V [libjvm.dylib+0x699145] JfrThreadSampler::task_stacktrace(JfrSampleType, JavaThread**)+0x225 V [libjvm.dylib+0x698ef7] JfrThreadSampler::run()+0x1d9 V [libjvm.dylib+0xb91837] Thread::call_run()+0x149 V [libjvm.dylib+0x9f7104] thread_native_entry(Thread*)+0x149 C [libsystem_pthread.dylib+0x3661] _pthread_body+0x154 C [libsystem_pthread.dylib+0x350d] _pthread_body+0x0 C [libsystem_pthread.dylib+0x2bf9] thread_start+0xd
28-01-2019