Suspected native memory leak in JavaCV when using FFmpegFrameGrabber

[KenFromNN]

Hello,

I have been struggling for several months with a native memory growth issue in production in a Spring Boot Java service that uses JavaCV to process incoming media files.

The service performs only a few operations with FFmpegFrameGrabber:

• Retrieves the media file's size and duration
• Generates preview images if the file is a video

However, the native memory usage of the service grows continuously during operation.
To work around this, I am forced to either restart the service periodically or keep increasing its memory limit.

Initially, I reviewed the service's legacy code and corrected several inconsistencies that could contribute to the issue.
I also researched similar reports in the JavaCV and JavaCPP GitHub repositories and applied all recommendations.
Specifically, I now:

• Use try-with-resources wherever possible for all JavaCV and JavaCPP types instances
• Explicitly call close() in finally blocks for resources where try-with-resources is not feasible due to code structure
• Wrap operations in a PointerScope (created via try-with-resources) before the FFmpegFrameGrabber

Unfortunately, none of these changes resolved the issue.

I also attempted to enforce memory limits by setting the following JavaCPP properties:

• org.bytedeco.javacpp.maxBytes = 256m (aligned with the ~250 MB Java heap)
• org.bytedeco.javacpp.maxPhysicalBytes = 576m (256 MB native + 256 MB heap + 64 MB extra buffer)

Despite this, after some time of successful operation, the service fails with:

ERROR com.mycompany.contentmanagementservice.domain.mediafiles.MediaFileService [http-nio-11513-exec-31] Fatal error in JavaCV native call
java.lang.OutOfMemoryError: Cannot allocate new PointerPointer(8): totalBytes = 24, physicalBytes = 716M
        at org.bytedeco.javacpp.PointerPointer.<init>(PointerPointer.java:151)
        at org.bytedeco.javacv.FFmpegFrameGrabber.startUnsafe(FFmpegFrameGrabber.java:934)
        at org.bytedeco.javacv.FFmpegFrameGrabber.start(FFmpegFrameGrabber.java:916)
        at org.bytedeco.javacv.FFmpegFrameGrabber.start(FFmpegFrameGrabber.java:911)
        at com.mycompany.contentmanagementservice.domain.mediafiles.MediaFileService.processMediaFile(MediaFileService.java:89)
        ...

The service processes only a small number of media files (typically 2–3 MB each) over its lifetime. Far too little to justify exceeding specified limits.

To help investigate, I have created a minimal reproduction project on GitHub:
JavaCVprofiling

The core logic is in the ThumbnailGenerator class.
It almost 100% mirrors the production code.

Could you please review it and advise whether I am missing anything critical for proper resource management or native memory control?

Additionally, I profiled this test application using async-profiler in nativemem mode (as described in its Native Memory Leaks documentation).

While I am not an expert in native profiling, it seems that the report shows a large number of native allocations without corresponding free() calls, suggesting a possible leak.
I have attached both the async-profiler report and an NMT (Native Memory Tracking) report for your reference:

• native-leaks.html
• nmt-final.log

Thank you very much for your time and support, I would greatly appreciate any guidance on how to resolve this problem.

[saudet]

Please try again with JavaCV 1.5.12. And if that still doesn't work, please try again with the snapshots:
https://central.sonatype.com/service/rest/repository/browse/maven-snapshots

[saudet]

And you're not calling FrameGrabber.close() anywhere. You'll need to call the close() method if you do not want any leaks.

[KenFromNN]

Hello @saudet

I am already on JavaCV version 1.5.12.

The org.bytedeco.javacv.FFmpegFrameGrabber extends the org.bytedeco.javacv.FrameGrabber which implements the java.io.Closeable interface.

I am using the FFmpegFrameGrabber in try-with-resources statement:

try (PointerScope scope = new PointerScope();
        FFmpegFrameGrabber grabber =
            FFmpegFrameGrabber.createDefault(fileInfo.getFilePath().toString())) {
   ...
}

Therefore when the try block finishes, either normally or due to an exception, the close() method of the resource must be automatically called.

Anyway, I'll try to change my code to call close() explicitly and let you know is anything changed.

[saudet]

Ah, I'm sorry. I missed that.

It would help to know if the issue is happening in FFmpegFrameGrabber, OpenCVFrameConverter, or Java2DFrameConverter