[FFmpeg-devel] [PATCH] Fix for memory leak in mov format

Baptiste Coudurier baptiste.coudurier
Wed Jun 18 10:31:27 CEST 2008

Art Clarke wrote:
> On Tue, Jun 3, 2008 at 3:24 PM, Baptiste Coudurier <
> baptiste.coudurier at smartjog.com> wrote:
>> Hi,
>> Art Clarke wrote:
>>>>>>> [...]
>>>>>>> Description of problem:
>>>>>>> The mov demuxer allocates some private data on each AVStream it adds,
>>>>>>> but never frees the data.
>>>>>>> How to reproduce:
>>>>>>> Use av_open_input_file() to open a .mov file, then call
>>>>>>> av_close_input_file().  Run program through a memory checking tool
>> (e.g.
>>>>>>> valgrind).
>>>>>>> Description of fix:
>>>>>>> When closing a .mov format file, free the allocated MOVContext object
>>>>>>> and null the AVFormatContext->priv_data value.
>>> [...]
>>> It's been over two weeks and no one had comments on this patch (either
>>> rejected or accepted).  Can someone let me know if it's OK, and if so,
>> how
>>> to commit it (I'd rather not keep my source tree out of sync with the
>> tip).
>> Yes, sorry.
>>> Issue: mov format leaks memory when opening and closing a file.
>>> Patch: attached.
>> Yes, and sorry but this has been discussed already. Ideally it should be
>> free in av_close_input_file assuming all demuxers allocate
>> st->priv_data, to avoid code duplication and to be consistent with
>> muxing code (write trailer).
>> Path is ok otherwise.
>> [...]
> Thanks Baptiste,
> I'll take a look to see if that's still necessary with current tip of tree,
> and submit a new patch if it's needed (and I can figure it out).

Well, had another report about this issue, patch applied then.

Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.                                http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA

More information about the ffmpeg-devel mailing list