-
-
Notifications
You must be signed in to change notification settings - Fork 925
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
File descriptors from stdlib jars are leaked when ScriptingContainers are terminated #3928
Comments
We've experimented with a hack to workaround this problem for now. The hack involves calling Here's a commit which includes this hask: camlow325/jruby9k-benchmarks@e1a05cc This obviously isn't an ideal fix for a number of reasons, including the use of reflection to access various private / package-private classes and fields and lack of regard for thread-safety around the use of the jar cache. Also, I'm not sure if the JRubyClassLoader associated with a We're hoping that there would be a more straightforward way that this issue could be addressed within the JRuby library itself. |
FWIW, I have noticed that when running some duration tests with my attached hack / workaround for this problem that we occasionally see error messages from Ruby code being run in a separate This may suggest that these jar file handles may be utilized by more than a single |
Link with #4112. |
This commit adds some hacky logic to the InternalScriptingContainer class to cleanup jar files and associated file descriptors when the container is terminated. This code is compensating for work that will hopefully be done in JRuby itself at some point, as part of a resolution for jruby/jruby#3928.
This commit adds some hacky logic to the InternalScriptingContainer class to cleanup jar files and associated file descriptors when the container is terminated. This code is compensating for work that will hopefully be done in JRuby itself at some point, as part of a resolution for jruby/jruby#3928.
This commit adds some hacky logic to the InternalScriptingContainer class to cleanup jar files and associated file descriptors when the container is terminated. This code is compensating for work that will hopefully be done in JRuby itself at some point, as part of a resolution for jruby/jruby#3928.
This commit adds some hacky logic to the InternalScriptingContainer class to cleanup jar files and associated file descriptors when the container is terminated. This code is compensating for work that will hopefully be done in JRuby itself at some point, as part of a resolution for jruby/jruby#3928.
Fixed by #4747. |
Environment
JRuby 9.1.1.0, run from a Java program via
ScriptingContainer
, withsetCompileMode
set toOFF
.Expected Behavior
ScriptingContainer
instances should be able to be created and terminated without leaking memory or other resources, such as file descriptors.Actual Behavior
When a
ScriptingContainer
is constructed and executes any Ruby code that results in certain jar-based libraries being loaded fromjruby-stdlib
, there are file descriptors opened pointing to the relevant library jars. When aScriptingContainer
is terminated, these descriptors (which seem to be referenced in a global cache) are not cleaned up.The cache appears to use weak references, so presumably at some point the memory used by these objects could be reclaimed, but because there is also an open file descriptor associated with each cache entry, it is likely that a program that is recycling
ScriptingContainer
instances will exceed the open file descriptor limit and crash before there is enough memory pressure to cause these objects to be GC'd.Here is a reproducer that illustrates the issue:
https://github.com/cprice404/jruby9k-benchmarks/tree/651c7ee063d0bf652293fe5c48b5ced3b80e6ade/jar-file-desc-leak
In the reproducer, we just do
require
s on a few libraries likeopenssl
,psych
,json/ext
. Here is somelsof
output that shows file descriptors for jars that definitely seem related to those libraries (bouncycastle, etc.):The text was updated successfully, but these errors were encountered: