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

David Holmes dholmes at openjdk.java.net
Fri Jan 8 03:52:56 UTC 2021


On Thu, 17 Dec 2020 08:10:24 GMT, Mauro Lacy <github.com+11656534+maurolacy at openjdk.org> wrote:

>>> Besides, I don't think the same is true of the other `Release` methods. This happens only with the `Critical` variant.
>> 
>> Sorry for (contributing to) the confusion. The reported double free error always mentions `ReleasePrimitiveArrayCritical`, but as Dmitry says, this ends up affecting both APIs.
>
> Hi David,
> 
> Thanks for researching this thoroughly.
> What you propose is reasonable, given the circumstances: undocumented or badly documented usage in the specs, and a lot of existing code (even in books, etc) that use `JNI_COMMIT` basically as `0`. We faced the same weeks ago, when looking for examples, documentation, and use cases for this functionality.
> 
> A couple comments:
> - Given that `JNI_COMMIT` is then effectively useless, maybe a good idea would be to deprecate it. This will break existing code, true, but a deprecation notice can be used, by example in the form of a compilation warning or so, for code that calls / uses it. Same in the docs, i. e. this is kept for historical reasons but will be deprecated soon, and so on.
> - I think in this case the best for us would be to simply drop support for `JNI_COMMIT` in the Rust JNI library. At least, for the ArrayCritical methods.

Hi @maurolacy can you please close this PR in favour of https://github.com/openjdk/jdk/pull/1816. Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/1697


More information about the hotspot-dev mailing list