libavformat/libavcodec might leak some memory when muxing a flac stream into a matroska container

[pbelkner]

Summary of the bug:
How to reproduce:

Apply the patch provided as attachment to the example program "<ffmpeg>/doc/example/muxing.c" and run it with valgrind:
~$ valgrind --leak-check=yes muxing ./muxing.mkv
==1944== Memcheck, a memory error detector
==1944== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1944== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==1944== Command: muxing ./muxing.mkv
==1944==
[flac @ 0x4ac4980] encoding as 24 bits-per-sample
Output #0, matroska, to './muxing.mkv':
    Stream #0:0: Video: mpeg4, yuv420p, 352x288, q=2-31, 400 kb/s, 25 tbn
    Stream #0:1: Audio: flac, 44100 Hz, stereo, s32 (24 bit), 64 kb/s
pts:0 pts_time:0 dts:0 dts_time:0 duration:0 duration_time:0 stream_index:0
pts:0 pts_time:0 dts:0 dts_time:0 duration:104 duration_time:0.104 stream_index:1

...

pts:9960 pts_time:9.96 dts:9960 dts_time:9.96 duration:0 duration_time:0 stream_index:0
pts:10031 pts_time:10.031 dts:10031 dts_time:10.031 duration:0 duration_time:0 stream_index:1
==1944==
==1944== HEAP SUMMARY:
==1944==     in use at exit: 210 bytes in 5 blocks
==1944==   total heap usage: 19,441 allocs, 19,436 frees, 12,505,320 bytes allocated
==1944==
==1944== 100 (12 direct, 88 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 5
==1944==    at 0x482F584: memalign (vg_replace_malloc.c:857)
==1944==    by 0x482F69B: posix_memalign (vg_replace_malloc.c:1020)
==1944==    by 0xCA5797: av_malloc (mem.c:87)
==1944==    by 0xCA5A7A: av_mallocz (mem.c:238)
==1944==    by 0xC92D8A: av_buffer_ref (buffer.c:95)
==1944==    by 0x3988D7: av_packet_ref (avpacket.c:625)
==1944==    by 0x272202: mkv_write_packet (matroskaenc.c:2537)
==1944==    by 0x272202: mkv_write_flush_packet (matroskaenc.c:2561)
==1944==    by 0x1DEF25: write_packet (mux.c:747)
==1944==    by 0x1DEF25: av_write_trailer (mux.c:1259)
==1944==    by 0x1D3465: main (muxing_morphed.c:993)
==1944==
==1944== 110 (12 direct, 98 indirect) bytes in 1 blocks are definitely lost in loss record 5 of 5
==1944==    at 0x482D1BC: malloc (vg_replace_malloc.c:298)
==1944==    by 0x482F4E0: realloc (vg_replace_malloc.c:785)
==1944==    by 0xCA57FB: av_realloc (mem.c:144)
==1944==    by 0x39797A: av_packet_add_side_data (avpacket.c:315)
==1944==    by 0x397A31: av_packet_new_side_data (avpacket.c:341)
==1944==    by 0x3981DD: av_packet_copy_props (avpacket.c:586)
==1944==    by 0x3988C0: av_packet_ref (avpacket.c:611)
==1944==    by 0x272202: mkv_write_packet (matroskaenc.c:2537)
==1944==    by 0x272202: mkv_write_flush_packet (matroskaenc.c:2561)
==1944==    by 0x1DEF25: write_packet (mux.c:747)
==1944==    by 0x1DEF25: av_write_trailer (mux.c:1259)
==1944==    by 0x1D3465: main (muxing_morphed.c:993)
==1944==
==1944== LEAK SUMMARY:
==1944==    definitely lost: 24 bytes in 2 blocks
==1944==    indirectly lost: 186 bytes in 3 blocks
==1944==      possibly lost: 0 bytes in 0 blocks
==1944==    still reachable: 0 bytes in 0 blocks
==1944==         suppressed: 0 bytes in 0 blocks
==1944==
==1944== For counts of detected and suppressed errors, rerun with: -v
==1944== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
~$

[Carl Eugen Hoyos]

Please send your patch - made with git format-patch - to the FFmpeg development mailing list, patches are ignored here.

[pbelkner]

As per request I sent the following mail to FFmpeg-devel (cf. ​http://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242135.html):

This patch does not improve or fix something instead it is meant for
easily reproducing issue 7827 (as requested, cf.
​https://trac.ffmpeg.org/ticket/7827). I've to admit that I don't know
how to produce a patch by "git format-patch" instead it was made by "git
diff > muxing.patch".

[Jun Zhao]

Please try the patch: ​https://patchwork.ffmpeg.org/patch/12612/, Tks

[pbelkner]

As far as I can see this is a patch for "<ffmpeg>/libavformat/matroskaenc.c". To be honest: I'm not branching into FFmpeg-development. I provided a patch making it easy to reproduce the issue. Do with it what ever you like.

Cheers Peter

[pbelkner]

Can some developer please raise reproduced by developer? From FFmpeg-devel I have the impression that the issue is at least taken serious.

[Jun Zhao]

Peter, I've reproduced the memory leak issue with examples muxing.c （inspired by your patch.） when enabled the FLAC audio codec.

This is the patch V2（suggested by Andreas Rheinhardt after the V1 patch） to fix the memory leak: ​https://patchwork.ffmpeg.org/patch/12614/.

You can apply the patch V2, then verify. Thanks.

[pbelkner]

According to my test this should fix the issue:

peter@debian-9:~$ valgrind --leak-check=yes muxing ./muxing.mkv 
==6378== Memcheck, a memory error detector
==6378== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==6378== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==6378== Command: muxing ./muxing.mkv
==6378== 
Output #0, matroska, to './muxing.mkv':
    Stream #0:0: Video: mpeg4, yuv420p, 352x288, q=2-31, 400 kb/s, 25 tbn
    Stream #0:1: Audio: flac, 44100 Hz, stereo, s16, 64 kb/s
pts:0 pts_time:0 dts:0 dts_time:0 duration:0 duration_time:0 stream_index:0
pts:0 pts_time:0 dts:0 dts_time:0 duration:104 duration_time:0.104 stream_index:1

...

pts:9960 pts_time:9.96 dts:9960 dts_time:9.96 duration:0 duration_time:0 stream_index:0
pts:10031 pts_time:10.031 dts:10031 dts_time:10.031 duration:0 duration_time:0 stream_index:1
==6378== 
==6378== HEAP SUMMARY:
==6378==     in use at exit: 0 bytes in 0 blocks
==6378==   total heap usage: 19,437 allocs, 19,437 frees, 12,457,158 bytes allocated
==6378== 
==6378== All heap blocks were freed -- no leaks are possible
==6378== 
==6378== For counts of detected and suppressed errors, rerun with: -v
==6378== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
peter@debian-9:~$

[pbelkner]

Many thanks for the quick resolution to everyone involved notably Jun Zhao, Andreas Rheinhardt, and Hendrik Leppkes.