Massive memory leak while rendering a video from Shotcut

[MaddyGuthridge]

Link to associated post on Shotcut Forum. Most of the required info should be there.

Basically, melt.exe renders fine for an undefined number of frames, then begins to allocate ever-increasing amounts of memory (it has gotten to over 57 GB of usage before). I can't figure out the time scale of this due to it taking so long to allocate so much.

Link to project with this issue

MLT XML that can be given as a parameter to melt.exe (this can be tried as well as the one in the linked folder) - it has multithreading disabled which reduces the speed at which the memory leak happens (it gets up to about 80% before being killed rather than about 10%). final-job-2.txt

Hopefully this can be fixed soon, since it has made the software effectively unusable.

[ddennedy]

It does not make the software unusable; it is only found to be problem in this project or some use case exercised by this project. Calling the software unusable is very demoralizing. Good luck finding a volunteer to help you with this.

[MaddyGuthridge]

Sorry, I didn't mean it like that. To clarify, the bug only makes it unusable for this particular project (as far as I am aware). In 99% of cases, MLT and Shotcut are absolutely awesome pieces of software, which is why I'd love for this issue to be patched. Please don't interpret my bug report as general criticism of the software, or as a personal attack against its maintainers. That's not my intent in any way shape or form, and I'm really sorry if I gave that idea.

I'd hope that as a contributor, you or someone else who is familiar with the codebase would be able to help diagnose and patch the issue, as sadly my knowledge of C++ isn't good enough for me to contribute hugely to the project, although if there is a way that I could help out (possibly by cloning MLT and running the tests with debugging tools to identify where the memory is being lost), I'd happily help although I'd probably need some instructions since I'm neither good at C++ nor familiar with the codebase.

I'm sorry for the misunderstanding, and hopefully we can work to get a solution soon.

[MaddyGuthridge]

Bump?

[bmatherly]

Through a series of trial-and-error tests, I have been able to reduce the test file significantly:

final-job_reduced.xml.txt

Now it boils down to:

• One clip with a fre0r filter applied
• One track that that clip and an affine filter applied to the track

Some interesting observations:

• If I remove either filter, it does not fail.
• If I replace the frei0r filter with a different frei0r filter (saturation) it does not fail
• If I replace the position keyframes in the affine filter with a single position value, it does not fail
• If I change the project resolution to be smaller, it will still fail

Unfortunately, those observations do not lead me to a very narrow area to investigate.

[MaddyGuthridge]

@bmatherly Ayyyyyyy thanks so much for the investigation! One possible idea would be to try and compress all of it down so that the leak happens over a 2 second video (as opposed to the 17 minute one I created the issue in).

If the video is made short enough, it should be possible for a significant number of allocations to be made and not freed, whilst also not bringing down the entire system. That way, it'd be possible to run it with Valgrind and try to find the exact location where the unfreed allocations are coming from.

This should make it possible to debug it slightly more easily.

Out of curiosity, what is the name of the fre0r filter in Shotcut, so that I can get an better idea of what's happening?

When I have time in a month or so (currently dealing with the worst University subject I've ever tried), I could try to help out with this a little, although I'm not sure how much use I'd be, and the issue could already be resolved by then. All I'd really need is some instructions for installing dependencies to build Melt, since currently I get CMake errors due to missing dependencies, and I'm not really sure how to resolve them, since I'm not familiar with using dependencies with C++ projects.

[MaddyGuthridge]

One other thing I've found through the Windows Task Manager is that the allocations happen far sooner than it initially seems. For some reason they all seem to go onto the paging file, to the point where melt will barely use over 4 GB of physical RAM for most of the job, but the system will still lock up if you try to do anything that wants to access the page file. I found it would use all the available page file memory before beginning to fill into physical memory. I have no idea how that sort of behaviour could end up happening but it may help with investigating the issue.

[bmatherly]

Out of curiosity, what is the name of the fre0r filter in Shotcut, so that I can get an better idea of what's happening?

  <property name="mlt_service">frei0r.IIRblur</property>
  <property name="shotcut:filter">blur_gaussian</property>

It would be interesting for you to remove just that one filter from the original project and see if it succeeds for you. I have not tried that.

For some reason they all seem to go onto the paging file

That is a good observation. After enough tries, I found that I could predict if it would fail by 5% if the commit size had exceeded 4GB. I did not have to wait for my system to crash to see if the test would pass or fail.

[ddennedy]

@bmatherly was this fixed by b18f2805809454ce0b331658f86e82b9ce35a634 ?

[bmatherly]

@bmatherly was this fixed by https://github.com/mltframework/mlt/commit/b18f2805809454ce0b331658f86e82b9ce35a634 ?

For my test case, this fixed it: https://github.com/mltframework/mlt/commit/b18f2805809454ce0b331658f86e82b9ce35a634 And then this broke it: https://github.com/mltframework/mlt/commit/6eb55feadc623dcbcd210004716e237cf1c1929d

Here is a proposed change that does not leak for my test case: https://github.com/mltframework/mlt/pull/851

[ddennedy]

fixed in 453745bef