search

gyandeep8693 / javacv

Automatically exported from code.google.com/p/javacv
GNU General Public License v2.0
0 stars 0 forks source link

javacpp86427368675423 directories not removed #427

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
One of the libraries included in JavaCV (look like JavaCPP) leaves a pesky 
javacppXXXXX directory on every run. I do call 'release' on my 
FFmpegFrameRecorder. Is that a known leak or am I supposed to call some method 
to remove this directory?

Original issue reported on code.google.com by eug...@wearableintelligence.com on 11 Feb 2014 at 2:11

GoogleCodeExporter commented 9 years ago 
They should get removed, unless the JVM crashes, then we might need to clean 
them up manually. If you're saying that your application closes normally, but 
these files still remain, then could you please provide more details about your 
OS, etc? Thanks

Original comment by samuel.a...@gmail.com on 11 Feb 2014 at 2:13

GoogleCodeExporter commented 9 years ago 
Just tried a normal case - where I stop and release the recorder (albeit after 
encountering https://code.google.com/p/javacv/issues/detail?id=425) . The 
directory did not get deleted.

Original comment by eug...@wearableintelligence.com on 11 Feb 2014 at 2:21

GoogleCodeExporter commented 9 years ago 
Yes, and what's your OS?

Original comment by samuel.a...@gmail.com on 11 Feb 2014 at 2:22

GoogleCodeExporter commented 9 years ago 
Linux (Android)

Original comment by eug...@wearableintelligence.com on 11 Feb 2014 at 2:29

GoogleCodeExporter commented 9 years ago 
JavaCPP can't extract anything on Android, so it shouldn't happen... Under 
which directory do these subdirectories get created?

Original comment by samuel.a...@gmail.com on 11 Feb 2014 at 2:34

GoogleCodeExporter commented 9 years ago 
External storage root, ie sdcard

Original comment by eug...@wearableintelligence.com on 11 Feb 2014 at 3:14

GoogleCodeExporter commented 9 years ago 
And you're not calling `Loader.getTempDir()` anywhere in your code??

Original comment by samuel.a...@gmail.com on 11 Feb 2014 at 3:17

GoogleCodeExporter commented 9 years ago 
No

Original comment by eug...@wearableintelligence.com on 11 Feb 2014 at 3:21

GoogleCodeExporter commented 9 years ago 
Can you list the files in your application's APK files? It might help figure 
this out, thanks

Original comment by samuel.a...@gmail.com on 11 Feb 2014 at 4:03

GoogleCodeExporter commented 9 years ago 
Here are the related libraries if that's what you are asking for[image:
Inline image 1]

Original comment by eug...@wearableintelligence.com on 11 Feb 2014 at 5:47

GoogleCodeExporter commented 9 years ago 
Email fail. Here is the file again

Original comment by eug...@wearableintelligence.com on 11 Feb 2014 at 5:48

Attachments:

GoogleCodeExporter commented 9 years ago 
No, not the source files, but the output files, from the APK.

But I think I see what the problem is. You shouldn't be able to add 
ffmpeg-2.1.1-android-arm.jar and opencv-2.4.8-android-arm.jar to the CLASSPATH 
with the Eclipse plug-in: How did you do that? Can you provide the version of 
Eclipse and the version of the plug-in you are using?

Original comment by samuel.a...@gmail.com on 12 Feb 2014 at 5:59

GoogleCodeExporter commented 9 years ago 
I am using Android Studio ( which relies on gradle)

Original comment by eug...@wearableintelligence.com on 12 Feb 2014 at 6:36

GoogleCodeExporter commented 9 years ago 
Ah, I guess the question then is to figure out a way to make everything work 
nicely with Android Studio then. Let me know if you come up with any good ideas 
or make interesting discoveries in that direction, thanks!

Original comment by samuel.a...@gmail.com on 12 Feb 2014 at 6:48

GoogleCodeExporter commented 9 years ago 
I'm unclear. What do all those files and classpaths have to do with
removing the directory? Isn't there some sort of a release method that we
need to find and call (either on my end or in the library)?

Original comment by eug...@wearableintelligence.com on 12 Feb 2014 at 7:57

GoogleCodeExporter commented 9 years ago 
Android has its own special way of handling libraries for JNI. We used to be 
able to put them in a special directory, and it worked, but I'm not sure what 
we need to do for Android Studio.

JavaCPP comes with facilities for Java SE, but they shouldn't be used for 
Android, because it doesn't seem to work too well, as you can see. Android 
wasn't made for that.

Original comment by samuel.a...@gmail.com on 12 Feb 2014 at 8:04

GoogleCodeExporter commented 9 years ago 
Why don't you (or JavaCPP) use standard Java I/O?

Original comment by eug...@wearableintelligence.com on 12 Feb 2014 at 10:08

GoogleCodeExporter commented 9 years ago 
JavaCPP does, it's Android that doesn't support standard Java I/O:
http://developer.android.com/reference/java/io/File.html#deleteOnExit%28%29
"Note that on Android, the application lifecycle does not include VM 
termination, so calling this method will not ensure that files are deleted."

Android handles JNI libraries in a special way anyway, so if you figure out 
anything, please post your findings here, thank you.

Original comment by samuel.a...@gmail.com on 13 Feb 2014 at 1:15

GoogleCodeExporter commented 9 years ago 
Why use deleteOnExit when you can just use... delete? I can understand some
automatic behaviors not supported, but what can be simpler than sticking a
'delete' call in the 'release'?

Original comment by eug...@wearableintelligence.com on 13 Feb 2014 at 1:18

GoogleCodeExporter commented 9 years ago 
Sure, if you say so. Please try it out, and if it works, please upload you 
patch here, thanks!

Original comment by samuel.a...@gmail.com on 13 Feb 2014 at 1:20

GoogleCodeExporter commented 9 years ago 
BTW, you could also try this:
https://groups.google.com/forum/#!msg/adt-dev/nQobKd2Gl_8/Z5yWAvCh4h4J
If it works, let me know, and I'll be sure to package the JAR files 
appropriately in the future, thanks.

Original comment by samuel.a...@gmail.com on 13 Feb 2014 at 3:08

GoogleCodeExporter commented 9 years ago 
To make this clear, Android has a special way of handling JNI libraries, for 
which we do not need to create any temporary directories. So, unless you have a 
reason to want to create temporary directories, the best way to avoid this 
issue is to build your application in a way that does not force JavaCPP in 
creating temporary directories, as it seems to be possible as per the link I 
refer to in the previous message. 

So, let me know if that approach works or not, thanks!

Original comment by samuel.a...@gmail.com on 16 Feb 2014 at 1:31

GoogleCodeExporter commented 9 years ago 
I've made changes in this revision of JavaCPP for that:
    http://code.google.com/p/javacpp/source/detail?r=93bbeb9e7ac72f528ccab7c45c779523d79fc618
If you have some time, please try it out with the Presets:
    http://code.google.com/p/javacpp/wiki/Presets
and let me know how it goes! Thanks

Original comment by samuel.a...@gmail.com on 30 Mar 2014 at 5:13

GoogleCodeExporter commented 9 years ago 
Starting with JavaCV 0.8, the .so files inside the JAR files for Android are 
not placed in the /lib/ subdirectory as indicated by the hack above, so that 
should fix this issue. If it does not, please let me know.

A lot of other things have changed with this new version, so please make sure 
to read the news release here:
    http://bytedeco.org/release/2014/04/28/first-release.html

This new version also comes with easier to use build scripts, so please take 
advantage of that to try out different things to satisfy your needs.

Thanks for testing this out for me!

Original comment by samuel.a...@gmail.com on 29 Apr 2014 at 1:36