[x265] Memory leak introduced with revision 6d14b538caa6

[Steve Borho]

On Mon, Aug 26, 2013 at 10:45 AM, Steve Borho <steve at borho.org> wrote:

>
>
>
> On Mon, Aug 26, 2013 at 3:58 AM, Nikos Barkas <nikbar2004 at yahoo.com>wrote:
>
>> This is a heads up for a quite serious memory leak that surfaced on
>> commit 6d14b538caa6 (split DPB logic and data from TEncTop into a
>> separate class). Any large file encoding after this revision will result
>> in all system memory being consumed and a crash. This has been tested on
>> Windows 7 with a MinGW build and I can confirm that the "stairway to crash"
>> is clearly visible (and quite steep, too) on the Task Manager screen.
>>
>> With this in the usability of the encoder is crippled, as it is currently
>> able to process only very small files. Hope that pinpointing the revision
>> where this was introduced will help fix it relatively quickly.
>>
>
> Leaks are pretty easy to debug on Windows.  You just install Visual Leak
> Detector, build for debug, then run a short encode.  It will dump memory
> leaks to x265_leaks.txt.  In this case, entire pictures are being leaked.
>  I'm investigating.
>

This turned out to be simple, but a little obscure.  The free list was
being passed as a copy instead of a reference.  I'm a little surprised none
of the compilers complained about that.

Fix pushed.

-- 
Steve Borho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.videolan.org/private/x265-devel/attachments/20130826/2fcaec06/attachment.html>