On Wed, 8 Mar 2023 09:05:19 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 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. ------------- PR: https://git.openjdk.org/jdk/pull/12920
