JDK-8261354 : SIGSEGV at MethodIteratorHost
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-02-08
  • Updated: 2025-01-25
  • Resolved: 2021-05-22
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 15 JDK 16 JDK 17
11.0.12Fixed 13.0.13Fixed 15.0.9Fixed 16.0.2Fixed 17 b24Fixed
Related Reports
Relates :  
JDK-8230400 - Missing constant pool entry for a method in stacktrace
Description
This started happening in 11.0.7 and is still the case in 11.0.10

The application is using solely the Java JFR Event API to create and register a dynamic event. The event is unregistered upon JVM exit and the recording is started with 'dumponexit=true'.

The error is not happening in JDK 15 (haven't checked with 12, 13 or 14)

===
Stack: [0x00007000054fe000,0x00007000055fe000],  sp=0x00007000055fd9f0,  free space=1022k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x3e78a2]  MethodIteratorHost<JfrTypeWriterHost<JfrPredicatedTypeWriterImplHost<Method const*, SerializePredicate<Method const*>, &(write__method(JfrCheckpointWriter*, void const*))>, 39u>, Wrapper<Klass const*, EmptyStub>, BitMapFilter, false>::operator()(Klass const*)+0xac
V  [libjvm.dylib+0x3e7756]  void JfrArtifactSet::iterate_klasses<CompositeFunctor<Klass const*, MethodIteratorHost<JfrTypeWriterHost<JfrPredicatedTypeWriterImplHost<Method const*, LeakPredicate<Method const*>, &(write__method__leakp(JfrCheckpointWriter*, void const*))>, 39u>, Wrapper<Klass const*, EmptyStub>, BitMapFilter, true>, MethodIteratorHost<JfrTypeWriterHost<JfrPredicatedTypeWriterImplHost<Method const*, SerializePredicate<Method const*>, &(write__method(JfrCheckpointWriter*, void const*))>, 39u>, Wrapper<Klass const*, EmptyStub>, BitMapFilter, false> > >(CompositeFunctor<Klass const*, MethodIteratorHost<JfrTypeWriterHost<JfrPredicatedTypeWriterImplHost<Method const*, LeakPredicate<Method const*>, &(write__method__leakp(JfrCheckpointWriter*, void const*))>, 39u>, Wrapper<Klass const*, EmptyStub>, BitMapFilter, true>, MethodIteratorHost<JfrTypeWriterHost<JfrPredicatedTypeWriterImplHost<Method const*, SerializePredicate<Method const*>, &(write__method(JfrCheckpointWriter*, void const*))>, 39u>, Wrapper<Klass const*, EmptyStub>, BitMapFilter, false> >&) const+0x2e
V  [libjvm.dylib+0x3e6127]  JfrTypeSet::serialize(JfrCheckpointWriter*, JfrCheckpointWriter*, bool)+0x5f5
V  [libjvm.dylib+0x3bd9ff]  JfrCheckpointManager::write_type_set()+0x75
V  [libjvm.dylib+0x3d877f]  JfrRecorderService::post_safepoint_write()+0x15
V  [libjvm.dylib+0x3d8633]  JfrRecorderService::write()+0x83
V  [libjvm.dylib+0x3d843f]  JfrRecorderService::rotate(int)+0x81
V  [libjvm.dylib+0x3d94e9]  recorderthread_entry(JavaThread*, Thread*)+0xbb
V  [libjvm.dylib+0x76f462]  JavaThread::thread_main_inner()+0x82
V  [libjvm.dylib+0x76f2ac]  JavaThread::run()+0x174
V  [libjvm.dylib+0x76d188]  Thread::call_run()+0x68
V  [libjvm.dylib+0x61c663]  thread_native_entry(Thread*)+0x139
C  [libsystem_pthread.dylib+0x6109]  _pthread_start+0x94
C  [libsystem_pthread.dylib+0x1b8b]  thread_start+0xf
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk15u-dev/pull/256 Date: 2022-08-22 10:27:36 +0000
22-08-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk13u-dev/pull/390 Date: 2022-08-22 10:28:17 +0000
22-08-2022
Fix request (15u & 13u) Requesting backport to 15u & 13u for parity with in 11u. Although the crash is not reproduced in jdk15, it is still better to integrate the fix, similarly to 16 and 17. The patch applies cleanly. Tested with jdk/jfr and tier1.
22-08-2022
Fix request (16u): Same reasoning as for 11u.
23-05-2021
Changeset: 24623167 Author: Jaroslav Bachorik <jbachorik@openjdk.org> Date: 2021-05-22 09:17:45 +0000 URL: https://git.openjdk.java.net/jdk/commit/24623167ffbf8e192ef539fd0a969412719f850c
22-05-2021
[11u] Fix Request Please, approve this fix for backporting to JDK 11u. The likelihood of this crash happening is slightly higher in JDK 11 as adding private static methods during class retransformation is not technically prohibited. The fix is very low risk - the change is localised to a few lines of an isolated code. The fix applies cleanly and tier1 and jdk_jfr tests on Linux x64 are all passing.
22-05-2021
By bisecting I arrived at http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/e868302b0772 as the one where the failure occurs first. Further debugging showed that the problem is in the MethodIteratorHost trying to access a method at incorrect index - the InstanceKlass version under inspection has fewer methods than the initial number of methods retrieved from the current InstanceKlass version. This is related to my particular use case when the class transformer is adding `private static` methods which, although not officially supported, used to work pretty well pre-JDK15 (in JDK15 the possibility was removed in order not to update the JVMTI spec to allow this). Of course, for the current JDK versions this can not happen - but I think it is correct to re-retrieve the number of methods for each InstanceKlass version under inspection and not rely on it not being changed by class transformers.
21-05-2021