Valgrind reports Leak Definitely Lost at memalign (vg_replace_malloc.c:460)

[nstockma@…]

I'm not completely sure which component to file this bug under, but I have an mp3 file where Valgrind reports Leak Definitely Lost.

The mp3 file (5154-fuzzed-amharic.mp3) can be found inside the .tgz archive at the URL above. The bug is easily reproducible. Note that it does not cause MPlayer to crash.

I confirmed that this bug is reproducible on Linux OS, Debian x32 with the
latest subversion of MPlayer, dev-SVN-r27243-4.1.2.

I used a 32-bit Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz.

To reproduce:
wget ​http://www.metafuzz.com/testcases/976419-1459-2705914246-Leak_DefinitelyLost.tgz
tar xzfv 976419-1459-2705914246-Leak_DefinitelyLost.tgz
valgrind --leak-check=full mplayer 5154-fuzzed_amharic.mp3

Here is the output from valgrind and mplayer on my machine:

user@debian:~/Desktop$ valgrind --leak-check=full mplayer 5154-fuzzed_amharic.mp3
==32084== Memcheck, a memory error detector.
==32084== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==32084== Using LibVEX rev 1854, a library for dynamic binary translation.
==32084== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==32084== Using valgrind-3.3.1, a dynamic binary instrumentation framework.
==32084== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==32084== For more details, rerun with: -v
==32084==
MPlayer dev-SVN-r27243-4.1.2 (C) 2000-2008 MPlayer Team
CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (Family: 6, Model: 15, Stepping: 6)
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

Playing 5154-fuzzed_amharic.mp3.
libavformat file format detected.
[ea_cdata @ 0x863c670]Could not find codec parameters (Audio: adpcm_ea_xas)
LAVF_header: av_find_stream_info() failed

Exiting... (End of file)
==32084==
==32084== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 1)
==32084== malloc/free: in use at exit: 32,984 bytes in 12 blocks.
==32084== malloc/free: 145,959 allocs, 145,947 frees, 9,194,402,209 bytes allocated.
==32084== For counts of detected errors, rerun with: -v
==32084== searching for pointers to 12 not-freed blocks.
==32084== checked 2,763,848 bytes.
==32084==
================================================================================
==32084== 84 bytes in 1 blocks are definitely lost in loss record 3 of 5
==32084== Stack hash: 2662860786
==32084== at 0x401C882: memalign (vg_replace_malloc.c:460)
==32084== by 0x8547A94: av_malloc (mem.c:61)
==32084== by 0x8260675: av_new_packet (utils.c:210)
==32084== by 0x82624E0: av_get_packet (utils.c:224)
==32084== by 0x8277575: cdata_read_packet (eacdata.c:86)
==32084== by 0x825CD22: av_read_packet (utils.c:514)
==32084== by 0x826263C: av_read_frame_internal (utils.c:864)
==32084== by 0x8263535: av_find_stream_info (utils.c:1970)
==32084== by 0x81A312E: demux_open_lavf (demux_lavf.c:466)
==32084== by 0x811E2BE: demux_open_stream (demuxer.c:864)
==32084== by 0x811E591: demux_open (demuxer.c:991)
==32084== by 0x807792E: main (mplayer.c:3238)
==32084==
==32084== LEAK SUMMARY:
==32084== definitely lost: 84 bytes in 1 blocks.
==32084== possibly lost: 0 bytes in 0 blocks.
==32084== still reachable: 32,900 bytes in 11 blocks.
==32084== suppressed: 0 bytes in 0 blocks.
==32084== Reachable blocks (those to which a pointer was found) are not shown.
==32084== To see them, rerun with: --leak-check=full --show-reachable=yes

I have not attempted to review this bug to determine whether it represents a
security risk or not.

This bug was found using the catchconv fuzzer. It was found as part of the
SUPERB-TRUST 2008 project ( see ​http://www.truststc.org/superb/ ) and the
metafuzz project ( see ​http://metafuzz.com/, stack hash 2705914246).

Let me know if I can provide more information.

[reimar]

Seems to have been fixed at some point.