RFR: 8364314: java_lang_Thread::get_thread_status fails assert(base != nullptr) failed: Invalid base [v2]
Daniel D. Daugherty
dcubed at openjdk.org
Wed Jul 30 22:59:59 UTC 2025
On Wed, 30 Jul 2025 06:24:39 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> After the changes in JDK-8361912 we could "return " the carrier thread from `cv_internal_thread_to_JavaThread`, but before we hit the transition disabler the virtual thread could unmount. As a result when we execute this code:
>>
>> if (is_virtual) {
>> // 1st need to disable mount/unmount transitions
>> transition_disabler.init(jthread);
>>
>> carrier_thread = Handle(THREAD, java_lang_VirtualThread::carrier_thread(thread_h()));
>> if (carrier_thread != nullptr) {
>> java_thread = java_lang_Thread::thread(carrier_thread());
>> }
>> }
>>
>> we hit the implicit else where "`carrier_thread == nullptr`" and we do nothing, but `java_thread` still holds the old carrier, which we then perform the handshake operation with:
>>
>> void do_thread(Thread* th) override {
>> Thread* current = Thread::current();
>>
>> bool is_virtual = java_lang_VirtualThread::is_instance(_thread_h());
>> if (_java_thread != nullptr) {
>> if (is_virtual) {
>> // mounted vthread, use carrier thread state
>> oop carrier_thread = java_lang_VirtualThread::carrier_thread(_thread_h());
>> _thread_status = java_lang_Thread::get_thread_status(carrier_thread);
>> } else {
>>
>> But the `_java_thread` no longer has a carrier, so `get_thread_status` is passed null and we crash.
>>
>> Simple fix is to clear `java_thread` when we find a null carrier oop. Also added an assert to guard against a null carrier oop in the handshake code, and added some additional commentary.
>>
>> Testing:
>> - com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java
>> - tier 5 and 6
>>
>> Thanks
>
> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>
> - Remove from ProblemList
> - Merge branch 'master' into 8364314-threadSMR
> - 8364314: java_lang_Thread::get_thread_status fails assert(base != nullptr) failed: Invalid base
I just finished catching up on this other issue/PR:
[JDK-8361103](https://bugs.openjdk.org/browse/JDK-8361103) java_lang_Thread::async_get_stack_trace does not properly protect JavaThread
https://github.com/openjdk/jdk/pull/26119
And this comment from @sspitsyn stuck out to me w.r.t. to this fix:
https://github.com/openjdk/jdk/pull/26119#discussion_r2209135122
But, please, note that the JvmtiVTMSTransitionDisabler mechanism is enabled
only when there is a JVMTI agent. Otherwise, it has been disabled for scalability
purposes to exclude potentially high performance overhead at the VTMS
transition points.
The above comment from Serguei calls into question this suggested change that I posted on the PR:
https://github.com/openjdk/jdk/pull/26544/files#r2243188114
If the JvmtiVTMSTransitionDisabler only works when there's an agent attached,
I don't think we're protecting the carrier thread at all since it can become unmounted
at anytime when there's no agent.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26544#issuecomment-3138052866
More information about the hotspot-runtime-dev
mailing list