On Wed, 4 Jun 2025 05:28:21 GMT, Johannes Bechberger <jbechber...@openjdk.org>
wrote:
>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 281:
>>
>>> 279: stop_timer();
>>> 280: Atomic::store(&_stop_signals, true);
>>> 281: while (Atomic::load_acquire(&_active_signal_handlers) > 0) {
>>
>> There can be a race when `handle_timer_signal` has already passed
>> `_stop_signals` check but has not yet incremented `_active_signal_handlers`.
>
> Amy idea on how to fix it?
I added another _static_stop_signals field which should prevent this.
>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 472:
>>
>>> 470:
>>> 471: void handle_timer_signal(int signo, siginfo_t* info, void* context) {
>>> 472: assert(_instance != nullptr, "invariant");
>>
>> There can be an arbitrary delay in async signal delivery.
>> It's unlikely, but not impossible for `_instance` to be deleted by the time
>> signal handler is called. There should be a better way to synchronize with
>> JFR shutdown.
>
> Any ideas? Or is it something for a later PR?
I added another `_static_stop_signals` field which should prevent this.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125756115
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2125755428
