[FFmpeg-devel] Fix leaked dictionary in mp3dec
tguilbert at chromium.org
Sat Apr 8 02:13:33 EEST 2017
In Chromium code, we set s->metadata ahead of time, with a custom entry to
avoid id3v1 tag parsing.
Some recent changes in mp3dec.c meant that we had to update this code, and
in the process, we discovered this reference leak on our end.
I am submitting this patch as a general code hardening patch. I also
understand if our use case is unusual and that one may assume that
s->metadata is always NULL.
On Thu, Apr 6, 2017 at 11:32 PM, wm4 <nfxjfg at googlemail.com> wrote:
> On Thu, 6 Apr 2017 14:07:53 -0700
> Thomas Guilbert <tguilbert at chromium.org> wrote:
> > The patch didn't show up as properly formatted on
> > https://patchwork.ffmpeg.org/patch/3228/.
> > Re-submitting using no line wrap in the base64 attachment, and copying
> > contents of the patch for ease of review:
> > From fced5ab0e09f529397adddcb560d1a08f2df4840 Mon Sep 17 00:00:00 2001
> > From: Thomas Guilbert <tguilbert at chromium.org>
> > Date: Thu, 30 Mar 2017 18:23:29 -0700
> > Subject: [PATCH] Fix dictionnary leak in mp3dec
> > ---
> > libavformat/mp3dec.c | 1 +
> > 1 file changed, 1 insertion(+)
> > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> > index 0924a57843..fd8184cc0b 100644
> > --- a/libavformat/mp3dec.c
> > +++ b/libavformat/mp3dec.c
> > @@ -349,6 +349,7 @@ static int mp3_read_header(AVFormatContext *s)
> > int ret;
> > int i;
> > + av_dict_free(&s->metadata);
> > s->metadata = s->internal->id3v2_meta;
> > s->internal->id3v2_meta = NULL;
> So in which situations is s->metadata not NULL?
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel