[FFmpeg-devel] Memory leaks in Ffmpeg after changing vlc allocation approach
Thu Jun 19 23:44:27 CEST 2008
"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
> 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
> 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
> 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
> c) does anyone read this far into an e-mail?
mans at mansr.com
More information about the ffmpeg-devel