RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v8]

David Holmes dholmes at openjdk.org
Sat Nov 25 02:23:13 UTC 2023


On Fri, 24 Nov 2023 05:47:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reinstate mistakenly deleted comment
>
> This has gotten a lot more complicated. All I was suggesting was if this:
> 
> if (with_method_holders) {
>   method->clear_jmethod_id();
> }
> 
> could be changed to 
> 
> if (method->method_holder() == nullptr) {
>   method->clear_jmethod_id();
> }
> 
> Now I'm not at all sure what you are doing.

> @dholmes-ora Unfortunately, I can not just do `method->method_holder() == nullptr` as `method_holder()` is expanding to `Method::constants()->pool_holder()` and `Method::constants()` is expanding to `Method::constMethod()->constants()`. This can cause SIGSEGV if either `Method::_constMethod` or `ConstMethod::_constants` is NULL.

I'm getting a strange sense of deja-vu here. This API is flawed if you cannot even ask for the method holder without some intervening value causing a SEGV. I've lost sight of the big picture here in terms of the lifecycle of the Method we are querying, the methodID we may be clearing and the existence or not of a method_holder().

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

PR Comment: https://git.openjdk.org/jdk/pull/16662#issuecomment-1826190641


More information about the serviceability-dev mailing list