[FFmpeg-devel] Memory leaks in Ffmpeg after changing vlc allocation approach

[Måns Rullgård]

"Art Clarke" <aclarke at vlideshow.com> writes:

> Hi folks (well mostly Michael),
>
> We have a fairly comprehensive memory leak test system for our software
> here, and it's been impressive how solid ffmpeg has been in running through
> it without leaking (way to go folks).  This is super important as our
> current system design has Ffmpeg running inside a very-long-running server
> process.
>
> That said, Ffmpeg is now starting to show leaks for well-behaved
> applications due to heap-allocated memory that cannot be freed via any
> Ffmpeg API call.  Now the leaks themselves are one-time allocations that do
> not grow, so it's not causing us problems.  But it is breaking our test
> suite.

[...]

> Proposed design:
> This method can be called by test-code doing memory-leak tests, and it would
> have the purpose of calling any destruction code necessary for
> pre-registered objects.  People who call this must guarantee they never call
> another Ffmpeg function in that process.  This would allow the calls to
> h263_decode_init_vlc (and any other function that allocates a global heap
> object) to register clean-up handlers as follows:
>
> av_register_static_object(vlc, destructor_to_be_fired_later);
>
> and then when av_unregister_all is called, we could call all destructors.
>
> Signatures might look like:
> void av_unregister_all();
> void av_register_static_object(void * obj, void
> (destructor_to_be_fired*)(void*));
>
> I'd be happy to hack this together but wanted to check first:
> a) is there any other demand for this (if not, I'll just make sure we

I doubt it.

> suppress leaks as they show up in our test suite)?

Suppressing specific messages is easy with valgrind.

> b) is there any other purposed way to solve this?

Solutions need problems.  There is no problem, and hence there can be
no solution.

> c) does anyone read this far into an e-mail?

No.

-- 
M?ns Rullg?rd
mans at mansr.com