I came across this issue, and checked my own windows machine. I can verify that this is occuring on Windows underneath 1.7.5. While my machine gets rebooted weekly and %TMP% cleaned out, it could be an issue... seems I have invoked JRuby 250 times in the last 2 days...

So this only happens on Windows, and it is still happening today, yes?

I can confirm this is happening and I looked at my old windows box and I
have thousands of jffi copies on it. I don't think this has never not
happened on windows. It should be fixed but the next immediate question is
how we should fix it...

On Fri, Feb 21, 2014 at 1:30 PM, Charles Oliver Nutter <
notifications@github.com> wrote:

So this only happens on Windows, and it is still happening today, yes?

Reply to this email directly or view it on GitHubhttps://github.com//issues/1237#issuecomment-35764551
.

blog: http://blog.enebo.com twitter: tom_enebo
mail: tom.enebo@gmail.com

I ran all the sample code included in JRuby 1.7.12 windows release on Windows 7 x64 and do not see any jffi files left in my %TMP% directory. I think this bug has been fixed and can be closed now.

I am running Logstash 1.4.0 on Windows 7 /Windows 2003 and have the same problem. how did you resolve the issue?

@enigma69 It's worth noting that Logstash 1.4.0 is bundled with JRuby 1.7.11; if you go into the vendor folder and swap it out for a newer version such as jruby-complete-1.7.12.jar, do you still see the problem?

Yes, I tried this already, but had not joy.

I confirm it still occurs with 1.7.12 complete jar, simply running the following create the ffi tmp file:

java -jar jruby-complete-1.7.12.jar -e "require 'ffi'"

This is not actually an issue that is isolated to Windows. It turns out we're seeing it fill up disks in production on Linux! Though I'm sure our use-case is fairly different than the original reporter.

The case that I've discovered this is within redstorm within a running Storm cluster. I've got a Lookout proprietary reproduction (regrettably) using some internal code on JRuby 1.7.15 with the redstorm library which I can share with @mkristian and hope he can derive a better test case out of it.

The gist seems to be that when using some of our code, which I suppose loads ffi through some transitive dependency, then if the embedded ScriptingContainer or JVM exits for some unknown reason (uncaught exception is one example), the /tmp/jffi*.tmp files get left around.

I have a sneaking suspicion that unclean shutdowns of a JRuby ScriptingContainer will cause the issue and that behavior appears to happen rather otten inside of a Storm cluster.

hmm - I can reproduce it with this redstorm but still trying to get a nice tiny test-case

jffi does copy the native library file from the classloader to a tmp file. and then loads this file. finally this file will be declared as deleteOnExit. especially on windows this is unreliable.

my tests showed:

String lib = "some.native.library";
System.load( lib );
new File(lib).delete();

does work wuite well and matches my experience with linux. no idea about this approach on windows.

on the 1.2.7 tag of patch for https://github.com/jnr/jffi would be

diff --git a/src/main/java/com/kenai/jffi/internal/StubLoader.java b/src/main/java/com/kenai/jffi/internal/StubLoader.java
index 084b98d..b1bc09b 100644
--- a/src/main/java/com/kenai/jffi/internal/StubLoader.java
+++ b/src/main/java/com/kenai/jffi/internal/StubLoader.java
@@ -326,6 +326,7 @@ public class StubLoader {
         }

         System.load(dstFile.getAbsolutePath());
+        dstFile.delete();
     }

     /**

that version I ran wuth testsuite on jruby-1_7

the current master of jffi does produce lots of errors.

Hi Guys,

Can you please let me know in which version of jruby the issue is fixed?

I am using Logstash, i wan't to replace jruby-complete-1.7.11.jar with the right jar but i could not fine an information giving the right jar version. I downloaded 1.7.19 but not sure if it is fixed as i still have the jffi file created and not removed.

Thanks,
Abdoul

@dialloa JRuby 1.7.18

Thanks @rtyler Greatly appreciated

Guess what... This bug is back now, in JRuby 9k. Will debug a bit more and then submit an issue (or hopefully, PR).