[x264-devel] Delete the huge memory leak in x264.

[BugMaster]

On Tue, 27 Nov 2007 14:28:13 +0800, alexander tian wrote:
> hi, Loren
> Thanks for your answer. I want to discuss with you about question "3".
> The new "x264_frame_t" cause huge memory leak. My idea is to add
> two parameters in the structure "x264_t". The one parameter
> "i_x264_new_frame" is for counting the new frame number. The other
> parameter "*x264_new_frame[ ]" is for the new frame pointer.
> By using them we can create the frame structure at one position. In
> addtion, we can count how many frames we have created. So we delete
> the created frame completely at the end of encoding. 
> I test the method not only by single-thread but also by
> multi-thread. They all run well. Anyone could reference by the
> attached file. It runs on windows. 
> I must point out that my idea is not best. It has some redundant
> code in the program. So anybody could reference from it and change
> it. Maybe somebody have better idea to solve the problem. 
> I think it is only reference solution for the memory leak. Maybe
> the future version will not have memory leak with full design.

> 2007/11/26, Loren Merritt <lorenm at u.washington.edu>:
> On Mon, 26 Nov 2007, alexander tian wrote:

>> I found huge memory leak in the x264. There are at least 3 positions which
>> has memory leak. Such as below:
>>
>> 1. The function "x264_mb_analyse_load_costs" in file " analyse.c". Here only
>> "malloc" the buffer for the parameter "*p_cost_mv[52]". But not free them in
>> the end. It should be freed at the function "x264_encoder_close".

> This is intentional. p_cost_mv is shared across all instances of x264. I
> would have made it static const instead of malloced, but then I'd have to
> write the big table literally in the source code. I could still make it
> static non-const, but that wouldn't free any memory, it would just
> appease your leak detector.

>> 2. The parameter "i_refs" in the function "x264_macroblock_cache_end" should
>> be computed like in the "x264_macroblock_cache_init". Otherwise it will 
>> cause memory leak.

> Fixed, but no I don't have to duplicate the computation.

>> 3. Not all the new "x264_frame_t" are deleted at the end of encoding. So it
>> cause huge memory leak. 

> This has been reported before. My reason for not accepting the patch was
> that it conflicts with my experimental alternate threading scheme.

> --Loren Merritt
> _______________________________________________ 
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel

Hi, Alexander.
As Loren wrote this bug had been reported before and patchs for fixing
were submited (for example,
http://mailman.videolan.org/pipermail/x264-devel/2007-October/003634.html).

Hi, Loren.
Does "experimental alternate threading scheme" meens thread-pool?