On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> The test fails when the target JavaThread has is_exiting() status. In such a >> case the JvmtiExport::cleanup_thread(this) has already made a clean up of >> its jvmtiThreadState, so the JavaThread address returned by >> _state->get_thread() is 0xbabababababababa. >> The fix is to add a check for is_exiting() status into handshake closure >> do_thread() early. >> There following handshake closures are fixed by this update: >> - UpdateForPopTopFrameClosure >> - SetForceEarlyReturn >> - SetFramePopClosure > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL It seems somewhat subjective whether a thread that is exiting and thus still on its way to becoming "not alive" needs to report "not alive" versus "not suspended". As there appears to be no synchronization with the target in this case what stops it from transitioning to "is_exiting" the moment after the "is_exiting" check returns false, but before you hit the assertion? ------------- PR: https://git.openjdk.java.net/jdk/pull/6440
