On Wed, 8 Mar 2023 15:15:52 GMT, Daniel Jeliński <djelin...@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
