JDK-8334781 : JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 23,24
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-06-23
  • Updated: 2025-07-14
  • Resolved: 2024-07-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 23 JDK 24
23Fixed 24 b07Fixed
Related Reports
Relates :  
JDK-8361750 - JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant
Relates :  
JDK-8337514 - JFR crash: assert(((((JfrTraceIdBits::load(value)) & ((JfrTraceIdEpoch::this_epoch_bit()) << 8)) != 0))) failed: invariant
Relates :  
JDK-8323883 - JFR AssertionError: Missing object ID 15101
Description
Test: applications/runthese/RunThese8H.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/a4a7850a-7c35-410a-b879-d77fbb2f6087-S12578/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d0354406-c0ff-476e-8d2f-031519669c48/runs/4e171abe-b62c-430d-abf3-72ffa822a04b/workspace/open/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:160), pid=3544059, tid=3544107
#  assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant
#
# JRE version: Java(TM) SE Runtime Environment (24.0+4) (fastdebug build 24-ea+4-288)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 24-ea+4-288, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1460ec6]  ObjectSampleCheckpoint::add_to_leakp_set(InstanceKlass const*, unsigned long)+0x546
#

Seems to be a recurring failure mode over the years - lots of similar issues fixed in the past.
Comments
The fix for this bug is integrated in jdk-24+7-716.
17-07-2024
A pull request was submitted for review. Branch: jdk23 URL: https://git.openjdk.org/jdk/pull/20217 Date: 2024-07-17 11:21:04 +0000
17-07-2024
Changeset: 67979eb0 Branch: master Author: Markus Grönlund <mgronlun@openjdk.org> Date: 2024-07-17 11:17:10 +0000 URL: https://git.openjdk.org/jdk/commit/67979eb0771ff834d6d3d18ba5a8bfe161cfc2ce
17-07-2024
The attached description of the JFR TagMethod state machine describes this invariant: THEOREM Spec => [](Tagged(method) => Tagged(klass)) The bug in JDK-8323883 introduced a counterexample.
15-07-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/20171 Date: 2024-07-13 14:47:21 +0000
13-07-2024
These lines (added as part of JDK-8323883): https://github.com/openjdk/jdk/commit/737b4c515e082239579369d9806307b9f16c4816#diff-171ef0683beebc4e33808e8372d5686e46e99cacf554d20625543744d6a99d7eR99 added functionality to copy over JFR traceid tag bits for methods being replaced in the process of JVMTI Redefine / Retransform classes An artifact is considered tagged if its has its mark bit set (1) (in the lower 8-bits) AND its metabit (higher 8-bits) is cleared (0). But the metatag bits are only set after some epochs (they build up during runtime), and are not explicitly set on new method construction (like for example, for scratch klass methods). Copying over the existing tag bits onto a new method creates an inconsistency between the tag bits and the metabits (now missing) This can lead to a method being considered tagged when it is not. Only OR:in the lower 8-bits is ok to retain the basic tag functionality; the problem is that the end result is then set as a 16-bit value. This means that valid metatag bits (iff they existed) are overwritten (set to 0) which can lead to a method being considered tagged, when it is not (tag bit = 1, metabit = 0 (overwritten) ). I am working on a specification of the JFR tag bit state machine, to help explain how the JFR tag process works.
13-07-2024