On Fri, 30 May 2025 22:07:16 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: no need to copy array by ReleaseByteArrayElements

Thank you for review, Alex and Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/25422#issuecomment-2923826295

Reply via email to