JDK-8230400 : Missing constant pool entry for a method in stacktrace
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 8,11.0.4,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2019-08-30
  • Updated: 2021-06-30
  • Resolved: 2019-10-29
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 11 JDK 13 JDK 14
11.0.7Fixed 13.0.4Fixed 14 b21Fixed
Related Reports
Duplicate :  
JDK-8232997 - V [libjvm.dylib+0x3ab826] JfrEventClassTransformer::on_klass_creation
Relates :  
JDK-8234059 - Stress test fails with "Unexpected Exception in thread JFR Event Stream"
Relates :  
JDK-8261354 - SIGSEGV at MethodIteratorHost
Relates :  
JDK-8233111 - Epoch shift synchronization point for Compiler threads
Description
Intermittently, JFR creates a recording where one or more methods in stack trace structures can not be resolved against the constant pool.

I am attaching the JSON fragment of such a corrupted recording.
Comments
Fix request (13u): The original change applies cleanly, tested with tier1 and jdk/jfr.
02-06-2020
Fix Request [11] This patch does not apply cleanly to 11u and requires adjustments. 11u RFR: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002444.html
03-02-2020
There are two root causes for this situation: 1. Incomplete tag support for JVMTI Retransform / Redefine of methods 2. Compiler thread(s) running outside the epoch shift protocol (a consequence of not adhering to safepoints) We will address 1 in this bug by adding support to traverse methods reachable also from InstanceKlass::previous_versions() when collecting tagged artifacts. This is because Retransform / Redefine allow multiple versions of the same method to exist in the system at the same time; threads can tag any one of these Method* to mark an interest (for example when taking a stacktrace). The fix also include stricter updates to the metadata, ensuring it is always valid (not stale) in native and subsequently the chunk to allow events to be parsed correctly. In addition, a corner case when processing ClassLoaderData in relation to unsafe anonymous klasses and ModuleEntry's has been identified and resolved. The situation relating to 2 will need to be fixed under a separate issue JDK-8233111.
29-10-2019
URL: https://hg.openjdk.java.net/jdk/jdk/rev/31ec3e55fa3d User: mgronlun Date: 2019-10-29 10:34:30 +0000
29-10-2019