Memory leak in 3.6.0 - Githubissues

chainikdn commented 4 years ago

How to reproduce: take MPC-HC (x64 to be specific) + ffdshow raw filter. Start playback, open ffdshow properties, put something memory-consuming into Avisynth script, e.g.

BicubicResize(5000,3000)
BicubicResize(1920,1080)

then check / uncheck Avisynth several times and observe memory usage via Task Manager.

3.6.0, 3.6.1: memory usage is rising with every check/uncheck cycle 3.5.1: memory usage is stable

I must say that the exact same issue were here years ago, but magically disappeared at some point after pinterf started its hard work.

Moreover, 3.6.1 crashes a lot. The simple way to reproduce is if you have SVP installed - then MPC-HC + AVS 3.6.1 crashes on every seek (after script reloading via on/off). Something is really wrong in 3.6 with cache or MT or both.

aportale commented 4 years ago

I can reproduce the memory consumption issue.

qyot27 commented 4 years ago

ffdshow has not been updated in years, and as memory serves, the 64-bit version was known for having issues.

Given the changes in 3.6 that also change how client programs using its API directly need to work, it doesn't surprise me that something could potentially cause ffdshow to freak out, although I'm reasonably sure it never used any of the unstable IScriptEnvironment2 API stuff that were what caused other programs and plugins to complain (the point, there, is that those programs/plugins had ignored the warnings that that API was unstable and subject to change and future breakage; it took 4+ years for it to happen, but with 3.6, it did).

Memory leaks are also kind of difficult to find. Especially on Windows, given the (un)willingness - on my part, anyway - to want to mess with MSVC's tools beyond the compiler itself. If the behavior can be replicated on Linux, where it can be debugged under a more fully controllable environment (be it through gdb, or Clang's analysis tools or sanitizers, or GCC's sanitizers) and the actual piece of the source responsible for the problem can be found, then there's a much better chance of resolving the matter. Of course, that relies on having something that actively refreshes an AviSynth script during playback, rather than fully unloading the entire script environment and the demuxer, the way libavformat does.

A robust way of handling this would, aside from setting up CI builds using the sanitizers¹, actually having some sort of unit testing framework that can verify whether changes to the behavior of functions or API introduce regressions (either like this or as incorrect output, assuming the cases used have deterministic outcomes). I believe unit testing was on the suggested projects page on the website, for the attempt at getting into GSoC several years back, but neither of those things ended up happening. And that particular page wasn't hosted on the gh-pages branch.

¹maybe even -Wall, too. Not every warning is necessarily critical to fix, but there's always the possibility some mixture of things we get warned about might interact in a way that lies at the heart of other issues people have.