On Wed, Jun 08, 2011 at 11:37:59PM +0300, Martin Storsjö wrote: > On Wed, 8 Jun 2011, Etienne Buira wrote: > > > On Wed, Jun 08, 2011 at 10:55:03PM +0300, Martin Storsjö wrote: > > > The original commit that this is a cherry-pick of actually > > > introduced a memory leak - this only fixes the potential > > > > What leak? If I trust libavformat/utils.c:avformat_free_context(), > > av_opt_free() is called so the hunk you removed is only a small cleanup. > > If that were the case, it'd be a case of mixing two different things in > the same commit - in the original form, it looked like it was related to > the change of av_free to av_freep, which it was clearly not.
It was related to use of av_opt_free, which will try to double free if not NULLed (and sorry for the obvious & mistake). > > You're welcome to state if I'm wrong. > > In the applehttp demuxer (which is the only place where the crypto > protocol is used today, and it's not usable standalone at the moment, > since you can't pass avoptions to protocols from the command line), the > input is closed manually via a plain ffurl_close (since it uses a custom > AVIOContext), where av_opt_free never is called on it. Also, even if it > was closed as a normal AVIOContext, we only call av_opt_free on the > AVFormatContext and its private data, not on the URLContext's private > data. > > To see it in action, try valgrinding "ffmpeg -i > 'http://albin.abo.fi/~mstorsjo/applehttp-crypt/prog_index.m3u8";. > > This cleanup could perhaps be done if we'd make ffurl_close call > av_opt_free on the private data, though - that might make sense. > > // Martin OK, thanks for the explanation. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
