On Fri, 30 May 2025 05:29:05 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> This update is fixing a couple of `nsk/jvmti/ scenarios` tests. >> The tests in a JVMTI `ClassFileLoadHook` callback provide new class file >> bytes with the result returned by JNI `GetByteArrayElements()`. It violates >> the JVMTI `ClassFileLoadHook` spec saying: >> >> "The agent must allocate the space for the modified class file data buffer >> using the memory allocation function Allocate because the VM is responsible >> for freeing the new class file data buffer using Deallocate." >> >> Please, see the JVMTI ClassFileLoadHook spec: >> >> https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#ClassFileLoadHook >> >> It is the root cause of a memory corruption detected with the VM option >> `-Xcheck:jni`. >> The fix is to convert a JNI allocated array returned by >> `GetByteArrayElements()` to a JMVTI allocated array. New conversion function >> `jni_array_to_jvmti_allocated()` is added to the`jvmti_common.hpp`. >> >> Testing: >> - ran updated tests individually >> - TBD: submit mach5 tiers 1-6 > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > review: add a call to ReleaseByteArrayElements to new function > jni_array_to_jvmti_allocated test/lib/jdk/test/lib/jvmti/jvmti_common.hpp line 466: > 464: > 465: memcpy(new_arr, jni_arr, (size_t)len); > 466: jni->ReleaseByteArrayElements(arr, jni_arr, 0); No need to update JNI array Suggestion: jni->ReleaseByteArrayElements(arr, jni_arr, JNI_ABORT); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25422#discussion_r2116672810
