RFR: 8320189: vmTestbase/nsk/jvmti/scenarios/bcinstr/BI02/bi02t001 memory corruption when using -Xcheck:jni [v3]
Serguei Spitsyn
sspitsyn at openjdk.org
Fri May 30 22:07:16 UTC 2025
> 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
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/25422/files
- new: https://git.openjdk.org/jdk/pull/25422/files/9f128798..086ceba4
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=25422&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=25422&range=01-02
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/25422.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/25422/head:pull/25422
PR: https://git.openjdk.org/jdk/pull/25422
More information about the serviceability-dev
mailing list