[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
avio_alloc_context().
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==
==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==
==8563== 1,048,608 bytes in 1 blocks are definitely lost in loss
record 279 of 279
==8563== at 0x4C28E62: realloc (in
/usr/local/stow/valgrind-3.9.0/lib64/valgrind/vgpreload_memcheck-
amd64-linux.so)
==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
/lib64/libpthread-2.11.1.so)
==8563== by 0xF9D970F: ???
==8563==
==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
shown.
==8563== To see them, rerun with: --leak-check=full --show-leak-
kinds=all
==8563==
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
opened.
- 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