-
Notifications
You must be signed in to change notification settings - Fork 747
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
Memory leak #878
Comments
Use PointerScope:
http://bytedeco.org/news/2018/07/17/bytedeco-as-distribution/
|
The entire test method is wrapped in a try block with a PointerScope. |
Ah, sorry, I missed that. Well, the only thing that could leak in that case is FFmpeg, so you'll probably find more help about that upstream: https://ffmpeg.org/contact.html |
ok, thanks |
Also be sure to try on Linux as well. If it doesn't happen there, then it's a bug in GCC on Windows. |
Yup, I'm unable to reproduce this on Linux, no crash or signs of a memory leak after over 2 hours, so it must be a bug in GCC on Windows. We need GCC to build FFmpeg itself, but we should still be able to compile the JNI wrappers with MSVC and that might help. Could you give it a try? It should only be a matter of removing these lines from the pom.xml file: https://github.com/bytedeco/javacpp-presets/blob/master/ffmpeg/pom.xml#L55-L83 The reason |
Ok thanks, sorry only just saw this - in the end I implemented that particular method in java. This may take me some time as I haven't worked with c for nearly 20 years. I'm just installing the tools... |
No worries, but I'm not able to reproduce this issue with Oracle JDK 8 on Windows 10 either, so it's probably not related to GCC. There must be something special about your particular machine... |
I have the same problem while called the same steps. @saudet |
Like I said, it works fine for me. I am unable to reproduce this issue. Unless you can provide any additional information, I will not be able to do anything about this. |
That's probably caused by something else in your application. If that doesn't concern you though, simply disable that check. |
@saudet
|
It's not needed with JavaCV 1.5.4 anymore, if that's what you're asking,
no.
|
I use ffmpeg preset with ffmpegPlatformVersion = '4.3.1-1.5.4', if or not needed? |
If you're using the API of FFmpeg directly, then, yes, any allocated Pointer should be used within a PointerScope. |
Ok. |
You can use those methods as well, but it's easier to use PointerScope, which will call them as needed. |
I see some of Pointer objects used xxReference() (e.g. video_pkt = new AVPacket().retainReference()) and some of Pointer objects not used xxReference() (avio = avio_alloc_context(new BytePointer(av_malloc(4096));) in FFmpegFrameRecorder.java, so some tricks or rules for this? |
Not really, it was just easier for me to do it without a PointerScope in those cases because I know how it works, but you don't need to do it that way. :) |
This is basically all you need to know: |
Yeh, I have seen it, so the PointerScope act as clearing the objects memory within the try(...) code block while it runs over immediately. |
I'm assuming that it's working fine now without memory leaks with all the fixes and everything, but please let me know if you're still having issues this! Thanks |
I'm struggling with a memory leak whilst calling certain ffmpeg functions.
The following code is an example, the problematic function call (av_guess_frame_rate) is commented out, without this line I can call this code many thousands of times without any signs of leak. With this line there is a steady increase in memory consumption and calls to Pointer.totalBytes() see an increase in 8 bytes per call.
I'm guessing that for some reason the AVRational is not being cleaned up. Running under the debugger the dealocator does appear to be called at the end of the try block.
Is there something else that I need to be doing here? I've tried all sorts of combinations of fr.releaseReference(), fr.deallocate(), fr.close() and Pointer.deallocateReferences().
I've also tried modifying the example program ReadFewFrame to run in a loop. That program takes only a few minutes to grab the maximum allowed memory before crashing.
My maven dependency is :
I'm running under Amazon Corretto 11.0.6_10 on Windows 10.
The text was updated successfully, but these errors were encountered: