RFR: 8318737: Fallback linker passes bad JNI handle

Jorn Vernee jvernee at openjdk.org
Wed Oct 25 10:08:38 UTC 2023


On Wed, 25 Oct 2023 10:01:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Not sure what you're saying here. As far as I understand the intent of this code is to check whether the handle is of a certain type, and if it's not recognized, return `JNIInvalidRefType`. So, I'm not sure there should be any `ShouldNotReachHere()` in this code.
>> 
>> We can add an `else` branch that returns `JNIInvalidRefType` though.
>
> The old code would throw `ShouldNotReachHere()` if we did not recognize the handle type:
> https://github.com/openjdk/jdk/blob/d2d1592dd94e897fae6fc4098e43b4fffb6d6750/src/hotspot/share/runtime/jniHandles.cpp#L207
> 
> I think the new code should still keep it, like so:
> 
> 
>  } else if (is_local_handle(thread, handle) || is_frame_handle(thread, handle)) {
>    ...
>  } else {
>    ShouldNotReachHere();
>  }
> 
> 
> That way, if we ever have another handle type, we would hit the `else` branch instead of silently returning `JNIInvalidRefType`. That is, our condition chain would still be exhaustive, catching unexpected values explicitly.

But that just re-introduces the bug? I don't see how we can have both `ShouldNotReachHere()` in the 'else branch' and return `JNIInvalidRefType` for unrecognized handles at the same time.

Not that this function is used to check potentially stale/invalid/corrupt JNI handles, so the input handle can be complete garbage.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16349#discussion_r1371485862


More information about the core-libs-dev mailing list