[10] Review Request: 8187442 Xcheck:jni produces various "WARNING in native method" in launcher

David Holmes david.holmes at oracle.com
Tue Sep 12 21:28:18 UTC 2017


Hi Sergey,

On 13/09/2017 7:22 AM, Sergey Bylokhov wrote:
> Hi, David.
> Thank you for review, here are my thoughts.
> 
> The patch uses the same pattern as NULL_CHECK0.
> 
> If an exception is occurred then NULL_CHECK0 in one situation and 
> CHECK_EXCEPTION_RETURN_VALUE in another situation will return 0 to the 
> upper code which will process this value(there is the same 0/null checks).
> 
> The difference between NULL_CHECK0 and CHECK_EXCEPTION_RETURN_VALUE, is 
> that the first is used when the "NULL" result also means some error, for 
> example:
>      NULL_CHECK0(mid = (*env)->GetStaticMethodID(env, cls,
>                  "getApplicationClass",
>                  "()Ljava/lang/Class;"));
> 
>      appClass = (*env)->CallStaticObjectMethod(env, cls, mid);
>      CHECK_EXCEPTION_RETURN_VALUE(0);
> 
> In the code above the GetStaticMethodID() returns NULL if the operation 
> fails, but it also throw an exceptions like NoSuchMethodError/etc.
> 
> But in case of CallStaticObjectMethod() we cannot check for NULL which 
> can be a valid result, so I added a check for exception and return 0.

My point is that the check is completely redundant. If an exception 
occurred then the return value is already 0/NULL. In addition this does 
nothing to clear the pending exception so I can not see how it would 
affect any warnings.

David

> This value will be propagated to JavaMain() and I as far as understand 
> will stop the execution.
> 
> 
> On 9/12/17 13:56, David Holmes wrote:
>> Hi Sergey,
>>
>> On 13/09/2017 5:18 AM, Sergey Bylokhov wrote:
>>> Hello,
>>> Please review the fix for jdk10/jdk10.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8187442
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8187442/webrev.00
>>
>> This doesn't look right to me:
>>
>>                str = (*env)->CallStaticObjectMethod(env, cls,
>>                        makePlatformStringMID, USE_STDERR, ary);
>> +             CHECK_EXCEPTION_RETURN_VALUE(0);
>>                (*env)->DeleteLocalRef(env, ary);
>>                return str;
>>
>> If there is an exception pending you fail to delete the local ref. And 
>> there's no need to clear the exception before calling DeleteLocalRef 
>> as that is okay to call with a pending exception. But there is no 
>> point returning zero if an exception occurred because in that case str 
>> will already be 0/NULL.
>>
>> The same here:
>>
>> 1596     appClass = (*env)->CallStaticObjectMethod(env, cls, mid);
>> 1597     CHECK_EXCEPTION_RETURN_VALUE(0);
>> 1598     return appClass;
>>
>> If an exception is pending then appClass will be 0/NULL.
>>
>> In addition CHECK_EXCEPTION_RETURN_VALUE doesn't clear the pending 
>> exception so I can't see what warnings this would be clearing up ???
>>
>> Thanks,
>> David
>> -----
>>
>>> The simple application with empty main method produce some "warnings" 
>>> when Xcheck:jni is used. Because of that it is hard to cleanup other 
>>> parts of jdk from such warnings.
>>>
>>> Two additional checks were added, in both cases the new code will 
>>> return 0 in the same way as NULL_CHECK0 in the same methods.
>>>
>>>
> 
> 


More information about the core-libs-dev mailing list