[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8269934: RunThese24H.java failed with EXCEPTION_ACCESS_VIOLATION in java_lang_Thread::get_t
From:       David Holmes <dholmes () openjdk ! java ! net>
Date:       2021-07-28 23:07:32
Message-ID: 3zSeaaAp2WYCrlDGi5j0y44z892n1y2KpyhIiwKu8OI=.d8f7e9ad-07da-48ce-b3ea-1e8912e9e9b8 () github ! com
[Download RAW message or body]

On Wed, 28 Jul 2021 14:22:07 GMT, Thomas Stuefe <stuefe@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
> 
> This looks good to me.
> 
> ..Thomas

Thanks for the reviews @tstuefe  and @dcubed-ojdk !

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

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


[prev in list] [next in list] [prev in thread] [next in thread]