RFR: 8034033: [parfait] JNI exception pending in share/native/sun/security/krb5/nativeccache.c

[Wang Weijun]

Webrev updated again at

   http://cr.openjdk.java.net/~weijun/8034033/webrev.02/

I add more checks to make sure it's a good initial TGT, and exit the loop when there is either an exception or the TGT is found. So there will be no exception pending and also no memory leak.

Thanks
Max

On Feb 15, 2014, at 9:14, Wang Weijun <weijun.wang at oracle.com> wrote:

> Hi Valerie
> 
> Since this is a while loop, it seems for each BuildXXX function, just returning NULL when an exception is thrown is not enough, because it's not returning to Java but still inside the native code so another JNI call might run. Do you think it's OK to add a ExceptionClear call after the cleanup label? This would suppress the exception but the returning value will most likely to be null in this case so IMO it's quite harmless.
> 
> In fact this loop is quite strange: it goes thru all creds, reads those for krbtgt and returns the *last* found one. During this loop, NewObject for krbCreds could be called several times. Will this cause a memory leak?
> 
> Also, the check made is "strncmp (serverName, "krbtgt", sizeof("krbtgt")-1) == 0" so this means a cross-realm TGT like krbtgt/THIS at THAT also matches. Now that the last one is returned this is more likely an issue because normally the initial TGT should appear before the cross-realm TGT. I'll need to look more into this and do some test.
> 
> Thanks
> Max
> 
> 
> On Feb 15, 2014, at 8:45, Valerie (Yu-Ching) Peng <valerie.peng at oracle.com> wrote:
> 
>> 
>> Hi, Max,
>> 
>> Just noticed that there is a JNIEnv->NewObject call on line 378. It looks like we have to check pending exception there also? This call is inside a while loop...
>> 
>> Rest looks fine.
>> Thanks,
>> Valerie
>> 
>>>   http://cr.openjdk.java.net/~weijun/8034033/webrev.01/
>