Re: RFR: JDK-8007607

: john.zavg...@oracle.com Cc: security-dev@openjdk.java.net Sent: Wednesday, March 13, 2013 9:07:45 PM GMT -05:00 US/Canada Eastern Subject: Re: RFR: JDK-8007607 Looks fine, just a very minor nit. - line 544: although the return value isn't really used, maybe you should return jlong_zero instead

Re: RFR: JDK-8007607

, 2013 9:07:45 PM GMT -05:00 US/Canada EasternSubject: Re: RFR: JDK-8007607 Looks fine, just a very minor nit. <GSSLibStub.c> - line 544: although the return value isn't really used, maybe you should return jlong_zero instead of -1 for consi

Re: RFR: JDK-8007607

Looks fine, just a very minor nit. - line 544: although the return value isn't really used, maybe you should return jlong_zero instead of -1 for consistency sake. Thanks, Valerie On 03/12/13 08:34, John Zavgren wrote: Greetings: I posted a new webrev image in response to the most recent rou

Re: RFR: JDK-8007607

Greetings: I posted a new webrev image in response to the most recent round of comments: http://cr.openjdk.java.net/~jzavgren/8007607/webrev.07/ Thanks! John On 02/19/2013 12:16 PM, Chris Hegarty wrote: Hi John, Functionally this

Re: RFR: JDK-8007607

- The implementation of throwByName(...) and throwOutOfMemory(...) should be moved to NativeUtil.c as that's where most if not all the utility functions are held. - I think it's better to move the block of code from line 330 to 333 to before the initGSSBuffer(...) call on line 329. Note that

Re: RFR: JDK-8007607

Hi John, Functionally this looks fine. Most my comments are nit picking, and style. src/share/native/sun/security/jgss/wrapper/GSSLibStub.c My fault, I think I suggested you return NULL, but since these methods return jlong they cannot (without generating warnings). It would be better to:

Re: RFR: JDK-8007607

Greetings: I posted a new webrev image. http://cr.openjdk.java.net/~jzavgren/8007607/webrev.04/ The code now throws an OOM exception when *alloc() fails, and the callers of procedures that call procedures that throw it, check for it.

Re: RFR: JDK-8007607

k.java.net Sent: Tuesday, February 12, 2013 11:04:28 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR: JDK-8007607 John, Changing everything for throw OOM is the right goal but it's a huge work to do - it's meaningless to throw OOM if all callers doesn't check for exception. I'

Re: RFR: JDK-8007607

gt; > John > > > - Original Message - From: dmitry.samers...@oracle.com To: > john.zavg...@oracle.com Cc: security-dev@openjdk.java.net Sent: > Tuesday, February 12, 2013 11:04:28 AM GMT -05:00 US/Canada Eastern > Subject: Re: RFR: JDK-8007607 > > John, >

Re: RFR: JDK-8007607

, if there are no negative consequences. John - Original Message - From: dmitry.samers...@oracle.com To: john.zavg...@oracle.com Cc: security-dev@openjdk.java.net Sent: Tuesday, February 12, 2013 11:04:28 AM GMT -05:00 US/Canada Eastern Subject: Re: RFR: JDK-8007607 John, Changing

Re: RFR: JDK-8007607

John, Changing everything for throw OOM is the right goal but it's a huge work to do - it's meaningless to throw OOM if all callers doesn't check for exception. I'm in doubt it could be done all at once and probably this problem should go to the huge TODO pile. So I'm speaking about *one particu

Re: RFR: JDK-8007607

On 02/08/2013 01:34 PM, Dmitry Samersoff wrote: 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 fil

Re: RFR: JDK-8007607

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

Re: RFR: JDK-8007607

what messages, if any, should I pass as their second argument, instead of NULL? Thanks! John - Original Message - From: dmitry.samers...@oracle.com To: john.zavg...@oracle.com Cc: security-dev@openjdk.java.net Sent: Friday, February 8, 2013 1:35:41 PM GMT -05:00 US/Canada Eastern Subje

Re: RFR: JDK-8007607

argument, instead >>of NULL? >> >> >> >>Thanks! >>John >>- Original Message - >>From: dmitry.samers...@oracle.com >>To: john.zavg...@oracle.com >>Cc: security-dev@openjdk.java.net >>Sent: Friday, February 8, 2013 1:35:41 PM GMT

Re: RFR: JDK-8007607

dule/Unix.c >> >> If so, what messages, if any, should I pass as their second argument, >> instead of NULL? >> >> >> >> Thanks! >> John >> - Original Message - >> From: dmitry.samers...@oracle.com >> To: john.zavg..

Re: RFR: JDK-8007607

k.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,

Re: RFR: JDK-8007607

- Original Message - From: dmitry.samers...@oracle.com To: john.zavg...@oracle.com Cc: security-dev@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 2

Re: RFR: JDK-8007607

John, In this particular case we MUST distinguish between (a) no channel bindings and basic context is all we have and (b) we can't process channel bindings for some reason. -Dmitry On 2013-02-08 23:01, Valerie (Yu-Ching) Peng wrote: > Right, the important thing is to throw OOM to indicate the

Re: RFR: JDK-8007607

Right, the important thing is to throw OOM to indicate the memory allocation failure. The return value won't matter. If the caller is a Java method, an OOM will occur when returning from this JNI call. If the caller is another JNI method, then the caller should check for pending error condition,

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/se

Re: RFR: JDK-8007607

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_BINDIN

Re: RFR: JDK-8007607

On 02/06/2013 12:44 AM, 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.0

Re: RFR: JDK-8007607

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 retu

Re: RFR: JDK-8007607

I think we need to throw OutOfMemoryError when malloc/realloc() calls return null. You can find a utility function in src/share/native/sun/security/pkcs11/wrapper/p11_util.c doing exactly that, i.e. throw OutOfMemoryError. Thanks, Valerie On 02/05/13 15:44, John Zavgren wrote: Greetings:

RFR: JDK-8007607

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