On Wed, 25 Jun 2025 13:02:03 GMT, Kevin Walls <kev...@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
