Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#7827 closed defect (fixed)

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

Reported by: pbelkner Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: mkv leak
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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)
~$

Attachments (1)

muxing.patch (1014 bytes ) - added by pbelkner 2 years ago.

Download all attachments as: .zip

Change History (10)

by pbelkner, 2 years ago

Attachment: muxing.patch added

comment:1 by Carl Eugen Hoyos, 2 years ago

Component: undeterminedavformat
Keywords: mkv leak added

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

comment:2 by pbelkner, 2 years ago

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".

comment:3 by Jun Zhao, 2 years ago

comment:4 by pbelkner, 2 years ago

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

comment:5 by pbelkner, 2 years ago

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

comment:6 by Jun Zhao, 2 years ago

Cc: mypopydev@gmail.com added
Version: unspecifiedgit-master

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.

comment:7 by pbelkner, 2 years ago

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:~$

comment:8 by Jun Zhao, 2 years ago

Cc: mypopydev@gmail.com removed
Resolution: fixed
Status: newclosed

comment:9 by pbelkner, 2 years ago

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

Note: See TracTickets for help on using tickets.