Fix JVM crash when Thread::current() returns nullptr (PROF-13072)#461
Open
Fix JVM crash when Thread::current() returns nullptr (PROF-13072)#461
Conversation
Race window between Profiler::registerThread() arming the CPU/wall-clock timer and thread_native_entry calling pd_set_thread(): if a profiling signal fires in that window ASGCT can be called with Thread::current()==null inside the JVM, crashing in JFR allocation paths (resource_allocate_bytes). Two complementary fixes: 1. Signal handlers (CTimer, WallClockASGCT): skip the sample when the JVM pthread key is initialized but the current thread has no JVM TLS value, i.e. pd_set_thread() has not yet run. 2. start_routine_wrapper / start_routine_wrapper_spec: move registerThread() inside the existing SignalBlocker so the timer is armed while signals are masked; any pending signal fires after unblocking and is discarded by (1). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Replace the permanent skip (JVMThread::current()==nullptr) with a one-shot init-window countdown per thread. JVM threads in the race window get one signal skipped; pure native threads (where JVMThread::current() is always null, e.g. NativeThreadCreator) are allowed through after the window expires, restoring their samples. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
CI Test ResultsRun: #24248400353 | Commit:
Status Overview
Legend: ✅ passed | ❌ failed | ⚪ skipped | 🚫 cancelled Summary: Total: 32 | Passed: 32 | Failed: 0 Updated: 2026-04-10 15:10:10 UTC |
Introduce start_window_and_register() noinline helper so that start_routine_wrapper_spec() never has sigset_t (SignalBlocker) on its own stack frame, preserving the original design that prevents musl's stack-protector canary corruption on aarch64. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?:
Fixes a JVM crash where
Thread::current()returnsnullptrinside ASGCT/JFR allocation paths when a profiling signal fires during thread initialization.Motivation:
There is a race window in
start_routine_wrapperbetweenProfiler::registerThread()(which arms the per-thread CPU timer, enabling SIGPROF delivery) androutine(params)(which callsthread_native_entry→pd_set_thread(), settingThread::current()in JVM TLS). If SIGPROF or SIGVTALRM fires in this window, ASGCT can be invoked on a thread whereThread::current()(ELF TLS) is stillnullptr, crashing in JFR allocation paths (resource_allocate_bytescalled from JfrStackTrace, JfrArtifactSet, etc.). This only manifests in virtualized environments where OS scheduling makes the race window much more likely to be hit.Additional Notes:
Two complementary changes:
Narrow the race window (
start_routine_wrapper,start_routine_wrapper_spec): moveProfiler::registerThread()inside the existingSignalBlockerscope. The timer is then armed while SIGPROF/SIGVTALRM are masked; any pending signal fires only after signals are re-enabled (but beforeroutine(params)) and is discarded by the guard below.Signal handler guard with one-shot init window (
CTimer::signalHandler,WallClockASGCT::signalHandler): whenJVMThread::isInitialized() && JVMThread::current() == nullptr, skip the sample — but only if the thread's_init_windowcountdown is still active (starts at 1, decremented on first skip).JVMThread::current()reads the JVM's own pthread TLS key (found during startup) — the same valuepd_set_thread()writes.The one-shot countdown distinguishes the two cases where
JVMThread::current()is null:SignalBlockerexits is skipped. POSIX guarantees at most one pending signal of each type, so by the time the window expires,pd_set_thread()has been called.NativeThreadCreator):JVMThread::current()is always null. The countdown expires after one skip, and all subsequent signals are sampled normally — no permanent loss of native thread samples.How to test the change?:
The crash reproduces only in virtualized environments. The benchmark at https://github.com/DataDog/java-profiler/tree/zgu/ctx_benchmark was used to trigger it originally. Unit-level reproduction is not feasible (race window requires specific scheduling that doesn't occur on bare metal reliably).
DynamicNativeThreadandNativeThreadTeston J9/glibc/aarch64 verify that the guard does not permanently suppress native (non-JVM) thread samples.For Datadog employees: