[Ffmpeg-devel] [PATCH] Fix leak of AVPacket data in ffserver

[Bryan Mayland]

Christian Iversen wrote:
> On Monday 23 January 2006 23:38, Bryan Mayland wrote:
>   
>> Bryan Mayland wrote:
>>     
>>> I was noticing that ffserver memory usage steadily grows over time.
>>> There are a couple reasons for this, but here is the big one.  When in
>>> the HTTPSTATE_SEND_DATA state, we're basically in a
>>> av_read_frame()/av_write_frame() loop.  If the av_write_frame doesn't
>>> need a flush (which is the case when writing low bitrate [96kbit] asf
>>> streams), nothing is written to the dynbuff and the code loops back to
>>> read more frames to fill the outgoing buffer.  In this case however,
>>> the data attached to the AVPacket is not freed with a call to
>>> av_free_packet.
>>> This patch fixes that in the common case as well as in the case a
>>> dynbuff could not be allocated.  NOTE:  This patch must be applied
>>> *after* my ffserver_warning_clean2.diff patch.
>>>       
> Is that "XXX: potential leak" connected to the fix you just sent here? In that 
> case, I vote for its removal :-)
>   
    After further review it looks like there is no more potential leak 
at that location.  Attached is the patch that fixes that and uses the 
proper coding standard brace placement on my new code. 

    There is still two pieces of code marked XXX: potential leak in the 
same function.  The first one will certainly still leak (since it 
allocates and doesn't change state which may cause a duplicate 
allocation), the second I think would be ok except for the fact that the 
server will get in a loop where it never will close that connection.

    There is another leak in libavformat/ffm.c:ffm_read_header() which 
leaks a small amount of memory for each connection.  The problem is that 
when it reads the video stream info, it does a strdup on the 
codec->rc_eq member.  This value is usually set to a const char* from 
the code segment ("tex^qComp"), therefore there is no easy way to know 
if this value should be freed when the codec is closed.  I have no idea 
how to fix that.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ffserver_packet_leak3.diff
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060124/a7d6e403/attachment.asc>