On Thu, 9 Mar 2023 08:21:15 GMT, Alexey Bakhtin <abakh...@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 > > @dfunch, @djelinski, @wangweij Thank you a lot for review and suggestions. > The customer uses its own native Kerberos provider. This provider can > allocate up to 2 MB of native memory per GSSContext until they are disposed. > An application can generate many contexts quickly and they are not cleaned up > until GC collects them. It causes high native memory consumption. So, the > main idea of the fix is to dispose context as soon as possible. > Unfortunately, in most cases, context is not yet established in the > `NegotiatorImpl::init` method after `initSecContext()`. So, we have no right > place in the `NegotiatorImpl` to dispose the context after > `NegotiatorImpl::init`. This is the reason I have to move the initiation of > context dispose into the `HttpURLConnection`. > `sun/security/krb5/auto/HttpNegotiateServer.java` and > `sun/security/krb5/auto/HttpsCB.java` tests can be used to verify that > `NegotiatorImpl::disposeContext()` is called correctly. > @alexeybakhtin thanks for adding more context. I believe @wangweij was > suggesting adding `context.dispose()` after `initSecContext` in > `NegotiatorImpl::nextToken`, which indeed looks like the right thing to do. Yes, after both `initSecContext` calls. In either case it's possible the context has already been established. ------------- PR: https://git.openjdk.org/jdk/pull/12920
