JDK-8323883 : JFR AssertionError: Missing object ID 15101
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 23
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-01-17
  • Updated: 2024-07-11
  • Resolved: 2024-02-14
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
23 b10Fixed
Related Reports
Relates :  
JDK-8322675 - JFR: Fail-fast mode when constants cannot be resolved
Relates :  
JDK-8326219 - applications/kitchensink/Kitchensink8H.java timed out
Relates :  
JDK-8334781 - JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant
Sub Tasks
JDK-8324229 :  
JFR: Temporarily disable assertion for missing object reference - Resolved
Description
Test failed in CI run with integration of JDK-8322675

[stress.process.err] Unexpected Exception in thread JFR Event Stream 2.
[stress.process.err] java.lang.AssertionError: Missing object ID 15101 in pool java.lang.Class. All IDs should reference an object
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.ConstantMap.get(ConstantMap.java:80)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.Reference.resolve(Reference.java:38)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.ConstantMap.resolve(ConstantMap.java:119)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.ConstantMap.resolve(ConstantMap.java:125)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.ConstantMap.get(ConstantMap.java:100)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.ConstantMap.lambda$resolve$0(ConstantMap.java:133)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.LongMap.forEachKey(LongMap.java:237)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.ConstantMap.resolve(ConstantMap.java:133)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.ChunkParser.lambda$readStreamingEvent$7(ChunkParser.java:218)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.LongMap.forEach(LongMap.java:246)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.ChunkParser.readStreamingEvent(ChunkParser.java:218)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.EventDirectoryStream.processOrdered(EventDirectoryStream.java:238)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.EventDirectoryStream.processRecursionSafe(EventDirectoryStream.java:166)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.EventDirectoryStream.process(EventDirectoryStream.java:126)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.AbstractEventStream.execute(AbstractEventStream.java:261)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.AbstractEventStream$1.run(AbstractEventStream.java:284)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.AbstractEventStream$1.run(AbstractEventStream.java:281)
[stress.process.err] 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:400)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.AbstractEventStream.run(AbstractEventStream.java:281)
[stress.process.err] 	at jdk.jfr/jdk.jfr.internal.consumer.AbstractEventStream.lambda$startAsync$1(AbstractEventStream.java:224)
[stress.process.err] 	at java.base/java.lang.Thread.run(Thread.java:1575)
Comments
Changeset: 737b4c51 Author: Markus Grönlund <mgronlun@openjdk.org> Date: 2024-02-14 14:10:28 +0000 URL: https://git.openjdk.org/jdk/commit/737b4c515e082239579369d9806307b9f16c4816
14-02-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/17771 Date: 2024-02-08 13:46:40 +0000
08-02-2024
Glad to see the added assertion in JDK-8322675 finding issues. Might not have to do with anything recently checked in, but latent bugs that have been around forever. It could take a few rounds before we are able to eliminate them all. If failures becomes too much of a noise, we can disable the assertion, but we need to drive out these bugs and it helps if we get more data and recording files to see where they happen. Some of them happen rarely and are hard to reproduce.
17-01-2024