RFR: JDK-8007607

[Michael StJohns]

It seems to me that this is a pretty common pattern.  Would it make better sense to define standard jni_malloc and jni_calloc functions that throw an OOM if the underlying allocation fails and use those rather than having to add the if statement check everywhere?

Mike



At 03:19 PM 2/8/2013, Valerie (Yu-Ching) Peng wrote:
>I think it's ok just to use NULL. An OOM is pretty self-explanatory. Most if not all invocations that I recall seeing simply use NULL.
>Valerie
>
>On 02/08/13 12:00, John Zavgren wrote:
>>All:
>>
>>I assume that anytime a "JNI" procedure in the native code experiences an OOM (Out Of Memory) error, then it should throw an exception, by executing:  JNU_ThrowOutOfMemoryError(env, NULL);
>>
>>src/share/native/sun/security/jgss/wrapper/GSSLibStub.c
>>src/share/native/sun/security/jgss/wrapper/NativeUtil.c
>>src/share/native/sun/security/smartcardio/pcsc.c
>>src/solaris/native/com/sun/security/auth/module/Solaris.c
>>src/solaris/native/com/sun/security/auth/module/Unix.c
>>
>>If so, what messages, if any, should I pass as their second argument, instead of NULL?
>>
>>
>>
>>Thanks!
>>John
>>----- Original Message -----
>>From: dmitry.samersoff at oracle.com
>>To: john.zavgren at oracle.com
>>Cc: security-dev at openjdk.java.net
>>Sent: Friday, February 8, 2013 1:35:41 PM GMT -05:00 US/Canada Eastern
>>Subject: Re: RFR: JDK-8007607
>>
>>John,
>>
>>>Ideas?
>>It's a JNI so just throw OOM.
>>
>>-Dmitry
>>
>>
>>On 2013-02-08 21:38, John Zavgren wrote:
>>>Although I agree that the name: "GSS_C_NO_CHANNEL_BINDINGS" is misleading,
>>>I can't identify anything else that seems more appropriate.
>>>
>>>The header file:
>>>/jdk8-tl/jdk/src/share/native/sun/security/jgss/wrapper/gssapi.h defines
>>>GSS_C_NO_CHANNEL_BINDINGS as follows:
>>>#define GSS_C_NO_CHANNEL_BINDINGS ((gss_channel_bindings_t) 0)
>>>
>>>The symbol matches the prototype of the function:
>>>
>>>     */*
>>>      * Utility routine which creates a gss_channel_bindings_t structure
>>>      * using the specified org.ietf.jgss.ChannelBinding object.
>>>      */
>>>     gss_channel_bindings_t getGSSCB(JNIEnv *env, jobject jcb) {
>>>       gss_channel_bindings_t cb;
>>>       jobject jinetAddr;
>>>       jbyteArray value;
>>>
>>>       if (jcb == NULL) {
>>>         return GSS_C_NO_CHANNEL_BINDINGS;
>>>       }
>>>         cb = malloc(sizeof(struct gss_channel_bindings_struct));
>>>
>>>         if(cb == NULL)
>>>             return  GSS_C_NO_CHANNEL_BINDINGS;*
>>>
>>>There doesn't appear to be anything in our set of options that is more
>>>suggestive of a memory allocation failure and the symbol:
>>>GSS_C_NO_CHANNEL_BINDINGS seems to be logically correct.
>>>
>>>Ideas?
>>>
>>>On 02/06/2013 04:57 AM, Dmitry Samersoff wrote:
>>>>John,
>>>>
>>>>Not sure GSS_C_NO_CHANNEL_BINDINGS; is correct return value for this case.
>>>>
>>>>I'm second to Valerie - it's better to throw OOM
>>>>
>>>>-Dmitry
>>>>
>>>>
>>>>On 2013-02-06 03:44, John Zavgren wrote:
>>>>>Greetings:
>>>>>
>>>>>I modified the native code to eliminate potential memory loss and crashes by checking the return values of malloc() and realloc() calls.
>>>>>
>>>>>The webrev image of these changes is visible at:
>>>>>http://cr.openjdk.java.net/~jzavgren/8007607/webrev.01/
>>>>>
>>>>>Thanks!
>>>>>John Zavgren
>>>
>>>-- 
>>>John Zavgren
>>>john.zavgren at oracle.com
>>>603-821-0904
>>>US-Burlington-MA