RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch [v5]

[Kevin Walls]

On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread.  This is hard to reproduce but a thread that has since terminated can provoke a crash.  Recognise this and return a null ThreadSnapshot.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - comment update
>  - comment update

I was reproducing this frequently, monitoring with asserts in a fastdebug build and problems started with
ThreadSnapshotFactory::get_thread_snapshot() getting a null from  JNIHandles::resolve(jthread) 

...there are several different crashes in the product build.

> But _thread_h() has already been used a number of times before we get here and if it were null we should have crashed long ago. ???

There can be some that don't cause a problem, like: java_lang_VirtualThread::is_instance(_thread_h());	(includes null check)
..and others are not called.  Hmm maybe there are some that look like they should have crashed, e.g.
1290      _thread_name = OopHandle(oop_storage(), java_lang_Thread::name(_thread_h()));	  <-- name does: return java_thread->obj_field(_name_offset);

...I don't see why this didn't fault in the report from the JBS issue I was interpreting here (not my debug build).  Reordered or something else happened, or just haven't understood enough.  It is much easier to read an assert in get_thread_snapshot than letting it continue and crash in vframestream etc...


But null from JNIHandles::resolve(jthread) is the earliest problem I found.

I'm redoing with the cv_internal_thread_to_JavaThread usage...

A little concerned that 
ThreadsListHandle::cv_internal_thread_to_JavaThread takes jobject jthread, our ref to a java.lang.Thread, and uses 
also calls
811    oop thread_oop = JNIHandles::resolve_non_null(jthread);

...which asserts if contains null, but maybe I don't know all the ThreadsListHandle magic.

I had a day yesterday where the problem would not reproduce at all, which made it hard to verify!  Will update...

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

PR Comment: https://git.openjdk.org/jdk/pull/25958#issuecomment-3012360012