On Mon, 13 Apr 2026 20:21:55 GMT, Chris Plummer <[email protected]> wrote:
>> Fixed three test files that fail with -Xcheck:jni on debug builds: >> >> popframe007.cpp: CallStaticVoidMethod in native B() was called with the >> declaring class (popframe007) instead of TestThread where the method ID >> belongs. Stored TestThread class as a global ref in getReady() and used it >> in B() >> >> aod.cpp: nsk_aod_agentLoaded() and nsk_aod_agentFinished() call >> CallStaticVoidMethod without checking for pending exceptions. Added >> nsk_aod_checkJNIException wrapper that describes, clears, and fails on >> unexpected exceptions. Fixes all 13 AttachOnDemand tests >> >> retransform003.cpp: ClassFileLoadHook callback calls CallObjectMethod and >> CallStaticObjectMethod without checking for pending exceptions. Added >> ExceptionCheck/ExceptionClear after both calls >> >> bi02t001 and bi03t001 pass without changes, NMT corruption issue from JDK 22 >> appears resolved on JDK 27 >> >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/PopFrame/popframe007/popframe007.cpp > line 197: > >> 195: Java_nsk_jvmti_PopFrame_popframe007_B(JNIEnv *env, jclass cls) { >> 196: if (mid != nullptr) { >> 197: env->CallStaticVoidMethod(testThreadClass, mid); > > Did this just end up getting an exception that we never handle anywhere? On debug builds with -Xcheck:jni, it catches the class/method ID mismatch and aborts with a fatal error before the call even executes. Without -Xcheck:jni, the behavior is undefined per the JNI spec. It could silently leave a pending exception or produce incorrect results. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30711#discussion_r3075637613
