[FFmpeg-devel] [PATCH] libavcodec/h264.c memleak bugfix

[Michael Niedermayer]

On Fri, Jan 25, 2008 at 03:17:14PM +0100, Zdenek Kabelac wrote:
> 2008/1/25, Michael Niedermayer <michaelni at gmx.at>:
> > On Fri, Jan 25, 2008 at 01:17:25PM +0100, Zdenek Kabelac wrote:
> > > 2008/1/25, Michael Niedermayer <michaelni at gmx.at>:
> > > > On Fri, Jan 25, 2008 at 12:16:46PM +0100, Zdenek Kabelac wrote:
> > > > > Hi
> > > > >
> > > > > context_init seems to overwrite already allocated allocated_edge_emu_buffer.
> > > > > So this patch frees it before it gets reallocated.
> > > >
> > > > rejected, your patch possibly introduces a double free
> > > > the allocated_edge_emu_buffer issue was discussed recently RTF(mailinglist)
> > >
> > > So may I assume you will fix this leak yourself ?
> >
> > no
> >
> >
> > > (reference counting??)
> >
> > ROTFL
> >
> 
> Am I missing some point here ?
> 
> Obviously there is memory leak during the h264 codec initialization
> sequence when MPV_common_init allocates edge buffer and then
> context_init from h264 rewrites this value.
> 
> I believe you are the h264 maintainer & expert  so you should probably
> know some better places where the edge should be released during the
> initialization if my patch leads to double-free risk (I definitively
> do not know internal details of h264) - so who else should know how to
> fix it ??
> 
> So what is so funny about this actually ??

that you suggest reference counting as solution for something which is never
used by more then one thing, its reference count would be 1 untils its freed


> Do you think the current code is correct ?

no, but
its only a minor bug, (does very little real harm) and great oppertunity
for new developers to become familiar with some of the code. And having
more people familiar with it is a very good thing

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080125/b21730dd/attachment.pgp>