Skip to content
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

Closed
ylgrgyq opened this issue Jun 8, 2016 · 4 comments
Closed

Leak in OpenSslContext #5372

ylgrgyq opened this issue Jun 8, 2016 · 4 comments
Assignees
Labels
Milestone

Comments

@ylgrgyq
Copy link

ylgrgyq commented Jun 8, 2016

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.

@normanmaurer
Copy link
Member

@ylgrgyq good catch! Let me fix this.

@normanmaurer normanmaurer self-assigned this Jun 8, 2016
@normanmaurer normanmaurer added this to the 4.0.38.Final milestone Jun 8, 2016
normanmaurer added a commit that referenced this issue Jun 9, 2016
…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
@normanmaurer
Copy link
Member

@ylgrgyq can you check #5380

normanmaurer added a commit that referenced this issue Jun 9, 2016
…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
normanmaurer added a commit that referenced this issue Jun 9, 2016
…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
@normanmaurer
Copy link
Member

Fixed by #5380

@ylgrgyq
Copy link
Author

ylgrgyq commented Jul 14, 2016

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 finalize is evil. It's performance is bad, when even weather it will be called is not determined. Maybe the object is already unreachable for a long time but finalize method on this object is not called which could lead to a lot of unreachable object linger on heap.

I admit that use finalize here is more user friendly, but still think an explicit termination method maybe much safer. Like showed in this issue, if let user call the termination method I think the OpenSslContext will not leak. WDYT?

liuzhengyang pushed a commit to liuzhengyang/netty that referenced this issue Sep 10, 2017
…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
pulllock pushed a commit to pulllock/netty that referenced this issue Oct 19, 2023
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants