RFR: 8303809: Dispose context in SPNEGO NegotiatorImpl

[Weijun Wang]

On Wed, 8 Mar 2023 15:15:52 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

>> This patch fixes a possible native memory leak in case of a custom native GSS provider.
>> The actual leak was reported in production.
>> 
>> sun/security/jgss, sun/security/krb5, sun/net/www/protocol/http jtreg tests are passed
>
> I'm not familiar with this code and don't know how to execute it, but since you mentioned  native memory leak...
> 
> I'm assuming NativeGSSConext is the class that holds a reference to the native memory. The class has a cleaner that is supposed to release the memory. It was recently refactored in JDK-8284490, and I think this refactoring introduced the leak. See:
> https://github.com/openjdk/jdk/blob/master/src/java.security.jgss/share/classes/sun/security/jgss/wrapper/NativeGSSContext.java#L374-L377
> `cleanable.clean()` calls `stub.deleteContext(pContext)`, but `pContext` is already zero.
> Before ffca23a5313855a6f9797ad6b342bb2e2cb1b49b `deleteContext` was called before setting `pContext` to zero.
> 
> In general, when fixing native memory leaks, please focus on fixing broken cleaners, rather than manually disposing the memory.

@djelinski Not a cleaner or lambda export, when `cleanable.clean()` is called, is it using its own copy of `pContext` and it's not reset to zero?

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

PR: https://git.openjdk.org/jdk/pull/12920