Opened 5 months ago

Closed 4 months ago

Last modified 4 months 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 5 months ago.

Download all attachments as: .zip

Change History (10)

Changed 5 months ago by pbelkner

comment:1 Changed 5 months ago by cehoyos

  • Component changed from undetermined to avformat
  • 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 Changed 5 months ago by 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".

comment:3 Changed 5 months ago by mypopy

comment:4 Changed 5 months ago by 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

comment:5 Changed 5 months ago by pbelkner

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 Changed 5 months ago by mypopy

  • Cc mypopydev@gmail.com added
  • Version changed from unspecified to git-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 Changed 5 months ago by 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:~$

comment:8 Changed 4 months ago by mypopy

  • Cc mypopydev@gmail.com removed
  • Resolution set to fixed
  • Status changed from new to closed

comment:9 Changed 4 months ago by pbelkner

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.