RFR: 8269934: RunThese24H.java failed with EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_thread_status

[Serguei Spitsyn]

On Wed, 28 Jul 2021 15:17:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> If a thread is attaching via JNI and has not yet created its Thread object it can be caught in a ThreadSnapshot during a thread dump (VM_DumpThreads) of all threads**, and the threadObj() will be NULL, so we can't pass it to get_thread_status().
>> 
>> ** JMM dumpThreads API
>> 
>> The initial fix simply checks for a NULL threadObj() and reports thread status NEW in that case.
>> 
>> Alternatively we could filter the attaching thread out completely in VM_DumpThreads::doit by expanding:
>> 
>>       if (jt->is_exiting() ||
>>           jt->is_hidden_from_external_view())  {
>>         // skip terminating threads and hidden threads
>>         continue;
>>       }
>> 
>> to also check jt->is_attaching_via_jni().
>> 
>> Note that higher-level code already filters out ThreadSnapshots with NULL threadObj() anyway so we could go either way.
>> 
>> Testing: manual hacks - see bug report.
>>   - tier 1-3 sanity testing
>> 
>> Thanks,
>> David
>
> src/hotspot/share/services/threadService.cpp line 879:
> 
>> 877:   // If thread is still attaching then threadObj will be NULL.
>> 878:   _thread_status = threadObj == NULL ? JavaThreadStatus::NEW
>> 879:                                      : java_lang_Thread::get_thread_status(threadObj);
> 
> I like the use of `JavaThreadStatus::NEW` here.
> 
> Since L867 creates the _threadObj OopHandle, do you want to change both
> uses of `threadObj` to `_threadObj()`? Is that still how we fetch the oop from
> an OopHandle? Or even use `threadObj()`... Then we don't have to reason
> about whether the `threadObj` oop is still good...

I was thinking about the same. If we always use _threadObj() then there is no need to make sure the threadObj is still valid.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4921