[Ffmpeg-devel] [PATCH] Fix leak of AVPacket data in ffserver
Tue Jan 24 20:02:53 CET 2006
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
>>> 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...
More information about the ffmpeg-devel