[x264-devel] Memory leaks in encoder.c

[BugMaster]

On Fri, 27 Jun 2008 00:35:44 +0200, Ralf Terdic wrote:
> Hi there,

> valgrind shows some memory leaks in encoder.c, it looks like some frames are
> not freed. For one encoding thread (see [1]), this is easily fixed:

> diff --git a/encoder/encoder.c b/encoder/encoder.c
> index 43f9f9f..e86935e 100644
> --- a/encoder/encoder.c
> +++ b/encoder/encoder.c
> @@ -1962,6 +1962,10 @@ void    x264_encoder_close  ( x264_t *h )
>      for( i = 0; h->frames.reference[i]; i++ )
>          x264_frame_delete( h->frames.reference[i] );
>  
+    if (h->>param.i_threads == 1) {
> +        x264_frame_delete( h->fdec );
> +    }
> +
>      /* rc */
>      x264_ratecontrol_delete( h );

> See [2] for valgrind results after the patch.

> But this doesn't help much with more than one encoding thread. It's quite
> difficult for me to understand what's going on. Each thread seems to have
> four stacks, the relevant ones seem to be thread->frames.unused and 
thread->>frames.reference. After the encoding, these stacks contain references 
> to some frames. x264_encoder_close deletes those frames that are referenced
> by stacks belonging to the *first* thread, but that's not enough, and I'm
> sure this causes the memory leaks.

> Unfortunately, you can't simply delete all frames referenced by all stacks,
> because some frames are referenced to by more than one stack, and I don't see
> how I could easily check whether a frame was freed already, except by doing
> lots of ugly comparisons. Any ideas?

> Ralf

> [1]
> # valgrind --leak-check=full --show-reachable=yes --leak-resolution=high
> x264 -o x264test.mp4 --fps 23.976 --crf 26 --threads 1 raw.yuv 640x480
> ...
> ==17829== 511,632 (3,152 direct, 508,480 indirect) bytes in 1 blocks are
> definitely lost in loss record 5 of 14
> ==17829==    at 0x4021A92: memalign (vg_replace_malloc.c:460)
> ==17829==    by 0x804EDEB: x264_malloc (common.c:728)
> ==17829==    by 0x806B143: x264_frame_new (frame.c:28)
> ==17829==    by 0x806B6AF: x264_frame_pop_unused (frame.c:889)
> ==17829==    by 0x8054D0B: x264_encoder_open (encoder.c:728)
> ==17829==    by 0x804B63B: main (x264.c:775)
> ...
> ==17829== LEAK SUMMARY:
> ==17829==    definitely lost: 3,152 bytes in 1 blocks.
> ==17829==    indirectly lost: 508,480 bytes in 13 blocks.
> ==17829==      possibly lost: 2,486,294 bytes in 14 blocks.
> ==17829==    still reachable: 3,496 bytes in 1 blocks.
> ==17829==         suppressed: 0 bytes in 0 blocks.

> [2]
> ==18883== LEAK SUMMARY:
> ==18883==    definitely lost: 0 bytes in 0 blocks.
> ==18883==      possibly lost: 720,918 bytes in 11 blocks.
> ==18883==    still reachable: 3,496 bytes in 1 blocks.
> ==18883==         suppressed: 0 bytes in 0 blocks.
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel

This topic rises here from time to time (at least twice). Also there
is my patch which fix this problem. But x264 developers for some
reason didn't want to include it in trunk (may be because such memory
leaks don't so important for CLI version of encoder which is closed
after encode and so also frees this memory by process termination).
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: x264_frames_memoryleak.r891.diff
Url: http://mailman.videolan.org/pipermail/x264-devel/attachments/20080627/b01f8144/attachment.txt