GNOME Bugzilla – Bug 766991
multifilesink: leaks memory when max-files property == 0
Last modified: 2016-12-31 09:59:11 UTC
Created attachment 328695 [details] [review] Patch If max-files == 0, multifilesink->files just keeps on growing as the pipeline carries on running, and there's nothing to prune down the list. Patch attached.
Comment on attachment 328695 [details] [review] Patch Nice catch, thanks for the patch! I think this makes sense in principle, but requires changes elsewhere in the code as well, e.g. gst_multi_file_sink_write_buffer() uses it in the NEXT_BUFFER case to determine if it's the first file or not and assumes it's always filled, for example. (Didn't check for other uses yet)
Ursula, do you think you'll be able to update the patch?
commit eb5ee5b7a366c6f8f216255d579aa669b908eafd Author: Tim-Philipp Müller <tim@centricular.com> Date: Sat Dec 31 09:52:25 2016 +0000 multifilesink: refactor max_files handling a bit Use GQueue instead of a GSList so we don't have to traverse the whole list to append something every time. And it also keeps track of the number of items in it for us. Add a function to add filenames to the list of old files and use it in more places, so that memory doesn't build up in other modes either if no max_files limit is specified. https://bugzilla.gnome.org/show_bug.cgi?id=766991 commit a10c1cc060648fd3ac6ab47d241f54eafc756248 Author: Ursula Maplehurst <ursula@kangatronix.co.uk> Date: Sun May 29 17:21:47 2016 +0100 multifilesink: don't leak memory when no max-files limit is set Technically we weren't leaking the memory, just storing it internally and never using it until the element is freed. But we'd still use more and more memory over time, so this is not good over longer periods of time. Only keep track of files if there's actually a limit set, so that we will prune the list from time to time. https://bugzilla.gnome.org/show_bug.cgi?id=766991