[x264-devel] Re: Fwd: Huge memory leak in x264_encoder_open

[Alex Izvorski]

Ofer,

You're right about the memory leak, however it seems the patch you
posted causes a crash if threads > 1.  Btw the leak is not fixed at
800k, it is simply number of threads*the size of a single frame, at
large resolutions it can be pretty big ;)   Seems like h->fdec (same as
h->threads[0]->fdec) can always be freed safely (and is not freed at
present) but other threads' fdec are somehow different.  The frames all
move through several queues, and also there are the frames in each
thread which (as I understand it) share the actual plane arrays with
frames in other threads.

Yes the correct procedure to help fix problems is to post a patch to the
mailing list.  Patches in diff -uNr format are preferred.  Please don't
feel that you're being ignored if you don't get an immediate response to
a patch (but yes do post it weekly or so as a reminder until you get a
response).  People are busy, and this is a volunteer project, but they
will get around to it when time permits.  This particular problem is not
something that is immediately obvious to me, so I'll have to pass it
along.

Speaking of "known to be stable", check out tools/regression-test.pl and
also make test.  It is a reasonable bet that x264 never has regressions
that can be detected with make test, but breakage may occasionally be
found with other combinations of options, or after changes which are
*supposed to* produce a non-identical bitstream.  I think now that we
have automated testing, every revision meets the same standard, except
possibly right after major feature additions.  That said, I think people
are open to ideas about a formal test/release process, if anyone was
willing to volunteer to do most of the work.

Regards,
--Alex

On Mon, 2007-05-21 at 15:48 +0300, Ofer Shem Tov wrote:
> I got the x264 sources a few weeks ago from the trunk. When using it I
> got a memory leak of around 800K between calling x264_encoder_open and
> x264_encoder_close without doing anything between the calls.
> 
> I looked at all the allocations and it seems that several large memory
> blocks are allocated in x264_encoder_open by x264_frame_pop_unused
> which calls x264_frame_new( h )
> 
>     for( i = 0; i < h->param.i_threads; i++ )
>     {
>         ...
>         h->thread[i]->fdec = x264_frame_pop_unused( h );
>         ...
>     }
> 
> This frame memory was not deallocated in  x264_encoder_close so I
> added one line to x264_encoder_close to free it and it solved the
> leak:
> 
>     for( i = h->param.i_threads - 1; i >= 0; i-- )
>     {
>         x264_macroblock_cache_end( h->thread[i] );
>         x264_frame_delete(h->thread[i]->fdec); // ***** this line
> solves the memory leak ****
>         x264_free( h->thread[i]->out.p_bitstream )
>         x264_free( h->thread[i] );
>     }
> 
> What is the process to get this sorted out by someone who is developing x264?
> 
> Related question is how do I know when to update my x264 sources to a
> newer version to something which is known to be stable? One idea is to
> follow some other project that is tested and use what it is using or
> just to take a snapshot when there is a week or so without any
> commits....no idea really how to do it
> 
> Ofer
> 

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html