[FFmpeg-trac] #5584(undetermined:new): FFmpeg libraries leak 1MiB memory chunks on corrupt files

FFmpeg trac at avcodec.org
Sun May 22 03:32:05 CEST 2016

#5584: FFmpeg libraries leak 1MiB memory chunks on corrupt files
             Reporter:  mocmaint     |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:  git-
  undetermined                       |  master
             Keywords:  memory leak  |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
 I am testing the next patchset for the MOC player which adds the ability
 to feed FFmpeg's libav* libraries input via the callbacks registered using
 avio_alloc_context().  Some of those tests involve corrupt, empty or
 otherwise corrupt or invalid files.

 When attempting to process a corrupt or invalid file the FFmpeg libraries
 leak a significant (> 1MiB) block of memory per file.

 As this is a library problem, there is no command line invocation of an
 FFmpeg utility, and those utilities do not appear to use callbacks via

 There is no console output (obviously) but the messages issued by the
 libraries (on one test file) are:

     Estimating duration from bitrate, this may be inaccurate
     Format flac detected only with low score of 1, misdetection possible!
     Could not find codec parameters for stream 0 (Audio: flac, 0
 channels): unspecified sample format
     Consider increasing the value for the 'analyzeduration' and
 'probesize' options

 The sequence of library calls (omitting error checking) is:

   AVFormatContext *ic = avformat_alloc_context();
   ic->pb = avio_alloc_context(...);
   avformat_open_input(ic, ...);
   avformat_find_stream_info(ic, ...);

 avformat_find_stream_info() fails with -541478725.

 ValGrind reports:

     ==8563== HEAP SUMMARY:
     ==8563==     in use at exit: 1,211,448 bytes in 4,717 blocks
     ==8563==   total heap usage: 41,887 allocs, 37,170 frees, 164,363,673
 bytes allocated
     ==8563== 1,048,608 bytes in 1 blocks are definitely lost in loss
 record 279 of 279
     ==8563==    at 0x4C28E62: realloc (in
     ==8563==    by 0x98D8940: ???
     ==8563==    by 0xAD7E38C: ???
     ==8563==    by 0xAE4AC24: ???
     ==8563==    by 0x96B8E29: ???
     ==8563==    by 0x96B94D3: ???
     ==8563==    by 0x44D605: play_file (player.c:763)
     ==8563==    by 0x44DCC9: player (player.c:899)
     ==8563==    by 0x420029: play_thread (audio.c:447)
     ==8563==    by 0x568397F: start_thread (in
     ==8563==    by 0xF9D970F: ???
     ==8563== LEAK SUMMARY:
     ==8563==    definitely lost: 1,048,608 bytes in 1 blocks
     ==8563==    indirectly lost: 0 bytes in 0 blocks
     ==8563==      possibly lost: 0 bytes in 0 blocks
     ==8563==    still reachable: 13,926 bytes in 124 blocks
     ==8563==         suppressed: 148,914 bytes in 4,592 blocks
     ==8563== Reachable blocks (those to which a pointer was found) are not
     ==8563== To see them, rerun with: --leak-check=full --show-leak-

 A suitable test file can be generated with:

     touch bad-flac.flac

 Additional notes:

 - This 1MB memory leak was introduced in FFmpeg commit 80a3a66.  Therefore
 it exists from FFmpeg 2.4 onwards and is still present in commit a0349ae2.
 - It was not present in either commit 3a19405 or commit 31e0b5d which
 commit 80a3a66 merged.
 - It is triggered when using callbacks for I/O and an empty file is
 - Also occurs with files containing random data.
 - It does not occur if callbacks are not used.
 - Size is always 1MiB + 32B: 1,048,608.
 - One such block is leaked for each corrupt or invalid file attempted.
 - The Xiph FLAC libraries handle these files without problems.

Ticket URL: <https://trac.ffmpeg.org/ticket/5584>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list