New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Leak in OpenSslContext #5372
Comments
@ylgrgyq good catch! Let me fix this. |
…bage collected Motivation: OpenSslClientContext / OpenSslServerContext can never be garbage collected as both are part of a reference to a callback that is stored as global reference in jni code. Modifications: Ensure the callbacks are static and so not hold the reference. Result: No more leak due not collectable OpenSslClientContext / OpenSslServerContext
…bage collected Motivation: OpenSslClientContext / OpenSslServerContext can never be garbage collected as both are part of a reference to a callback that is stored as global reference in jni code. Modifications: Ensure the callbacks are static and so not hold the reference. Result: No more leak due not collectable OpenSslClientContext / OpenSslServerContext
…bage collected Motivation: OpenSslClientContext / OpenSslServerContext can never be garbage collected as both are part of a reference to a callback that is stored as global reference in jni code. Modifications: Ensure the callbacks are static and so not hold the reference. Result: No more leak due not collectable OpenSslClientContext / OpenSslServerContext
Fixed by #5380 |
Hi, @normanmaurer Could you please tell me why OpenSslContext use finalize to release resources used by the Context? Why not just provide an explicit termination method and let the user to call it and do the releasing stuff in this termination method? Because, I think you already heard, a lot of people say that I admit that use |
…e garbage collected Motivation: OpenSslClientContext / OpenSslServerContext can never be garbage collected as both are part of a reference to a callback that is stored as global reference in jni code. Modifications: Ensure the callbacks are static and so not hold the reference. Result: No more leak due not collectable OpenSslClientContext / OpenSslServerContext
…e garbage collected Motivation: OpenSslClientContext / OpenSslServerContext can never be garbage collected as both are part of a reference to a callback that is stored as global reference in jni code. Modifications: Ensure the callbacks are static and so not hold the reference. Result: No more leak due not collectable OpenSslClientContext / OpenSslServerContext
OpenSslContext (I mean OpenSslClientContext or OpenSslServerContext exactly) object hold some resources (like custom verification callback to verify ssl certificate) which need to be released when this OpenSslContext object is GC. This is done by JVM calling
finalize
in OpenSslContext.But I found that OpenSslContext will never be GC so all the resources possessed by it will never be released. Take OpenSslClientContext as example but the same bug exists in OpenSslServerContext too. In the constructor of OpenSslClientContext, there's an anonymous class object which is used as a custom verification callback to verify certificate and is set into SSLContext by calling SSLContext.setCertVerifyCallback. This SSLContext.setCertVerifyCallback is a native function in which a global reference is created and ref to the custom verification callback passed to SSLContext.setCertVerifyCallback.
So the custom verification callback used to verify certificate will be released only when OpenSslClientContext object is GC. And the OpenSslClientContext object will be GC only when the custom verification callback is removed from JNI global reference.
The text was updated successfully, but these errors were encountered: