JDK-8360201 : JFR: Initialize JfrThreadLocal::_sampling_critical_section
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 25,26
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2025-06-23
  • Updated: 2025-07-03
  • Resolved: 2025-06-24
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 25 JDK 26
25Fixed 26 b04Fixed
Related Reports
Causes :  
Description
When running jtreg test   jdk/jfr/startupargs/TestStartDuration.java
with ubsan-enabled binaries, the following issue has been observed on
linuxaarch64 :

 stderr: [/priv/jenkins/client-home/workspace/openjdk-jdk-weekly-linux_aarch64-opt/jdk/src/hotspot/share/jfr/support/jfrThreadLocal.hpp:348:12: runtime error: load of value 108, which is not a valid value for type 'bool'
    #0 0xffff89a2b2a4 in JfrThreadLocal::in_sampling_critical_section() const src/hotspot/share/jfr/support/jfrThreadLocal.hpp:348
    #1 0xffff89a2b2a4 in build_from_context src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp:237
    #2 0xffff89a2b2a4 in JfrSampleRequestBuilder::build_java_sample_request(void const*, JfrThreadLocal*, JavaThread*) src/hotspot/share/jfr/periodic/sampling/jfrSampleRequest.cpp:302
    #3 0xffff89a66080 in OSThreadSampler::do_task(SuspendedThreadTaskContext const&) src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp:290
    #4 0xffff8a8800e8 in SuspendedThreadTask::internal_do_task() src/hotspot/os/posix/signals_posix.cpp:1848
    #5 0xffff89a642b8 in SuspendedThreadTask::run() src/hotspot/share/runtime/suspendedThreadTask.hpp:48
    #6 0xffff89a642b8 in OSThreadSampler::request_sample() src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp:281
    #7 0xffff89a642b8 in JfrSamplerThread::sample_java_thread(JavaThread*) src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp:304
    #8 0xffff89a64e34 in JfrSamplerThread::sample_java_thread(JavaThread*) src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp:222
    #9 0xffff89a64e34 in JfrSamplerThread::task_stacktrace(JfrSampleRequestType, JavaThread**) src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp:253
    #10 0xffff89a64e34 in JfrSamplerThread::run() src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp:195
    #11 0xffff8aa9b260 in Thread::call_run() src/hotspot/share/runtime/thread.cpp:243
    #12 0xffff8a33e854 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:868
    #13 0xffff8dcc2694 in start_thread (/lib64/libc.so.6+0x80694)
    #14 0xffff8dd2cbd8 in thread_start (/lib64/libc.so.6+0xeabd8)

Seems this is rather new, might be related to JDK-8352251 ?

Comments
A pull request was submitted for review. Branch: jdk25 URL: https://git.openjdk.org/jdk/pull/25952 Date: 2025-06-24 15:09:03 +0000
24-06-2025

Changeset: 5c1f77fa Branch: master Author: Aleksey Shipilev <shade@openjdk.org> Date: 2025-06-24 15:05:40 +0000 URL: https://git.openjdk.org/jdk/commit/5c1f77fab1f56e470157d8680310417924abb298
24-06-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25938 Date: 2025-06-23 16:16:48 +0000
23-06-2025

Ah yes, I confused myself. It is ubsan, not asan! Still, I cannot reproduce it locally. So I'll just go ahead and PR the fix, please try to see if ubsan works for you after this.
23-06-2025

> Does not seem to reproduce locally on Linux x86_64 with GCC 13 ASAN. So I am not able to verify the fix works. But I strongly suspect it is the fix. Hi [~shade] , we do not see this so far on Linux x86_64 with ubsan (not asan); only on Linux aarch64 with ubsan. Not sure what the asan sanitizer has to 'say' about this. I can try your fix, the explanation makes sense !
23-06-2025

Does not seem to reproduce locally on Linux x86_64 with GCC 13 ASAN. So I am not able to verify the fix works. But I strongly suspect it is the fix.
23-06-2025

I think I know what that is. `JfrThreadLocal::_sampling_critical_section` is not initialized, which means we effectively read garbage from there until the first proper "boolean" write. Can you try if ASAN is happy with this fix? ``` diff --git a/src/hotspot/share/jfr/support/jfrThreadLocal.cpp b/src/hotspot/share/jfr/support/jfrThreadLocal.cpp index 4b805a98a32..67d311e2a6e 100644 --- a/src/hotspot/share/jfr/support/jfrThreadLocal.cpp +++ b/src/hotspot/share/jfr/support/jfrThreadLocal.cpp @@ -79,7 +79,8 @@ JfrThreadLocal::JfrThreadLocal() : _enqueued_requests(false), _vthread(false), _notified(false), - _dead(false) + _dead(false), + _sampling_critical_section(false) #ifdef LINUX ,_cpu_timer(nullptr), _cpu_time_jfr_locked(UNLOCKED), ```
23-06-2025

[~mgronlun] , [~shade] could you maybe check if it is related to JDK-8352251 ?
23-06-2025