RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v7]

[Leonid Mesnik]

On Wed, 20 Aug 2025 05:35:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm very confused by this issue. The description indicates we are calling `get_jvmti_thread_state` from the wrong state, but nowhere here or in JBS do I see anything showing me the actual failing code path. JBS has a part of a hs_err file that reports "# fatal error: LEAF method calling lock? " but I don't see how that relates to the stated problem of being in the wrong state ??
> 

The comment in JBS shows the stacktrace from hs_err. I copied it here:
Stack: [0x00007f13537f9000,0x00007f13538f9000], sp=0x00007f13538f6b60, free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x10c4458] JavaThread::check_for_valid_safepoint_state()+0xc8 (javaThread.cpp:401)
V [libjvm.so+0x16fe5e1] Mutex::lock()+0x41 (mutex.cpp:119)
V [libjvm.so+0x1403b7b] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x39b (mutexLocker.hpp:204)
V [libjvm.so+0x140b178] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool) [clone .constprop.0]+0x98 (jvmtiExport.cpp:424)
V [libjvm.so+0x1415b57] JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x77 (jvmtiExport.cpp:1834)
V [libjvm.so+0x1066b86] InterpreterRuntime::post_method_exit(JavaThread*)+0xe6 (interpreterRuntime.cpp:1278)

Also, I updated another comment to show how to reproduce the bug. The testing is not integrated in CI yet. However, it could be reproduced using our tests.

Also, the problem could be quite easy reproduced if assertion from the patch is added to 
`
JvmtiExport::get_jvmti_thread_state(JavaThread *thread, bool allow_suspend) {
`

> Also you state `post_method_exit` is not called when the method terminates via an exception, but I can't see that as being the case. The MethodExit callback in JVMTI is called under all termination conditions and post_method_exit seems similarly unconditional. ??


The method 
`
void JvmtiExport::post_method_exit_inner(JavaThread* thread,
                                         methodHandle& mh,
                                         JvmtiThreadState *state,
                                         bool exception_exit,
                                         frame current_frame,
                                         jvalue& value) {
`
is used by 
`void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame) {`
to post MethodExit events.
And 
`
void JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) {
`
that also calls `JvmtiExport::post_method_exit_inner()` is used only when method exit normally. 

T `JvmtiExport::post_method_exit()` has the variable `exception_exit`.  This variable is set to true while the thread has exception that has been thrown but haven't caught yet.  It might happens if VM or JNI made upcall while thread has ES_DETECTED _exception_state. So current method is exit normally while thread is processing exception. Pretty rare case that is reproduced in the test 'ExceptionOccured'. 
The method is called from MethodExit event for the method where exception has been thrown.

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

PR Comment: https://git.openjdk.org/jdk/pull/26713#issuecomment-3204367348