RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234

[David Holmes]

Hi Dmitry,

On 15/12/2020 4:51 am, Dmitry Timofeev wrote:
> Hi David,
> 
> Thanks for submitting the issues!
> 
>> This particular issue is only about the GetCritical API in relation to
> the change in JDK-8193234 which introduced the explicit free of the
> internally allocated buffer used only for Xcheck:jni.
> 
> As
[`check_wrapped_array_release`](https://github.com/openjdk/jdk/blob/976acddeb5a8df1e868269787c023306aad3fe4a/src/hotspot/share/prims/jniCheck.cpp#L422-L441),
modified in JDK-8193234, is re-used in both
[ReleaseCritical](https://github.com/openjdk/jdk/blob/976acddeb5a8df1e868269787c023306aad3fe4a/src/hotspot/share/prims/jniCheck.cpp#L1887)
and
[ReleaseScalar](https://github.com/openjdk/jdk/blob/976acddeb5a8df1e868269787c023306aad3fe4a/src/hotspot/share/prims/jniCheck.cpp#L1717)
in checked mode, it is not just GetCritical API that is affected, but 
also GetXArrayElements methods.

Thanks for the correction - I'm not sure if I realized at the time that 
this affected both API's. :(

David
-----

> That is, a supposedly valid client code:
> 
> var buf = env->GetByteArrayElements(jarray, ...);
> // Just commit, do not free
> env->ReleaseByteArrayElements(jarray, buf, JNI_COMMIT);
> // Commit and free
> env->ReleaseByteArrayElements(jarray, buf, 0);
> 
> will result in an error with `check:jni` enabled. However, an incomplete usage, with a leak in client code:
> 
> 
> var buf = env->GetByteArrayElements(jarray, ...);
> // Just commit, do not free
> env->ReleaseByteArrayElements(jarray, buf, JNI_COMMIT);
> // buf is not freed
> 
> will neither trigger an error, nor cause a `buf` leak with `check:jni` mode enabled (because of JDK-8193234), but will leak without JNI checks.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1697
>