RFR: 8195690: JNI GetObjectRefType doesn't handle NULL

Kim Barrett kim.barrett at oracle.com
Tue Jan 23 01:33:24 UTC 2018

> On Jan 22, 2018, at 8:22 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Jan 22, 2018, at 5:29 PM, David Holmes <david.holmes at oracle.com> wrote:
>> Hi Kim,
>> As a general rule JNI does not do argument checking. You pass crud then you may crash:
>> "The programmer must not pass illegal pointers or arguments of the wrong type to JNI functions. Doing so could result in arbitrary consequences, including a corrupted system state or VM crash."
>> https://docs.oracle.com/javase/9/docs/specs/jni/design.html#reporting-programming-errors
> GetObjectRefType is specified to return JNIInvalidRefType when called with a NULL argument:
> https://docs.oracle.com/javase/9/docs/specs/jni/functions.html#getobjectreftype
> The bug was discovered by a failing JCK test; we are asserting (or possibly invoking undefined behavior) without this change.

BTW, having GetObjectRefType return JNIInvalidRefType for a perfectly valid (NULL) result from
(for example) NewGlobalRef is an oddity that I’m not going to touch here.

(We “canonicalize” JNI handle encapsulation of Java null as a C/C++ NULL.)

>> David
>> -----
>> On 23/01/2018 8:24 AM, Kim Barrett wrote:
>>> Please review this fix of GetObjectRefType when applied to a NULL
>>> handle argument.  It should return JNIInvalidRefType, but was instead
>>> asserting in debug builds, and maybe worse things in release builds.
>>> In addition to making GetObjectRefType handle NULL properly, various
>>> functions in JNIHandles and OopStorage now have non-NULL handle argument
>>> preconditions and corresponding assertions.
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8195690
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8195690/open.00/
>>> Testing:
>>> Mach5 {hs,jdk}-tier{1,2,3}
>>> Locally ran JCK vm/jni tests
>>> Locally ran tonga vm.runtime tests for jni tests

More information about the hotspot-runtime-dev mailing list