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

[David Holmes]

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

Something still bugging me about this one. From JBS it looked to me like we were dealing with a virtual thread but your change is for the non-virtual thread. And Alan says something about this only being possible due to a temporary condition. So I'm still unclear exactly what the problem is, or why it appeared. Where does the initial "thread" argument come from in the Java code? Is it the one that has terminated, if so why is there not an `isAlive()` check somewhere?

And how does this lead to the bad oop?

src/hotspot/share/services/threadService.cpp line 1477:

> 1475:     java_thread = java_lang_Thread::thread(thread_h());
> 1476:     if (java_thread == nullptr) {
> 1477:         return nullptr; // thread terminated

If you return here what does that mean for the null check at line 1483? Is that code now dead?

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

PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2959619173
PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2167605967