Opened 11 years ago

Closed 9 years ago

#1197 closed defect (worksforme)

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

Reported by: nstockma@… Owned by: reimar
Priority: normal Component: ad
Version: HEAD Severity: normal
Keywords: Cc: catchconv-bugreports@…
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:


Although this leak appears to be at the same place as Bug 1136, I am reporting it separately because it's stack trace is different.

Here I have an ogg file for which Valgrind reports a Memory Leak. The ogg file (hat.ogg) 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
following subversion of MPlayer: dev-SVN-r27291-4.1.2

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

To reproduce:
tar xzfv 97949-0-3209625344-result32512.tgz
valgrind --leak-check=full mplayer hat.ogg

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

user@debian:~/Desktop$ valgrind --leak-check=full mplayer hat.ogg
==28534== Memcheck, a memory error detector.
==28534== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==28534== Using LibVEX rev 1854, a library for dynamic binary translation.
==28534== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks? LLP.
==28534== Using valgrind-3.3.1, a dynamic binary instrumentation framework.
==28534== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==28534== For more details, rerun with: -v
MPlayer dev-SVN-r27291-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 hat.ogg.
[Ogg] stream 0: audio (Vorbis), -aid 0
Ogg file format detected.
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)
Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis decoder)
AO: [oss] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 5.7 (05.7) of 6.0 (06.0) 29.5%

Exiting... (End of file)
==28534== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 27 from 1)
==28534== malloc/free: in use at exit: 32,918 bytes in 13 blocks.
==28534== malloc/free: 3,385 allocs, 3,372 frees, 2,425,604 bytes allocated.
==28534== For counts of detected errors, rerun with: -v
==28534== searching for pointers to 13 not-freed blocks.
==28534== checked 2,935,984 bytes.
==28534== 10 bytes in 1 blocks are definitely lost in loss record 2 of 6
==28534== Stack hash: 2281209955
==28534== at 0x401C882: memalign (vg_replace_malloc.c:460)
==28534== by 0x85509B4: av_malloc (mem.c:61)
==28534== by 0x85509F9: av_strdup (mem.c:145)
==28534== by 0x82F53F1: avcodec_get_context_defaults2 (utils.c:744)
==28534== by 0x82F54B9: avcodec_alloc_context2 (utils.c:763)
==28534== by 0x82F54E1: avcodec_alloc_context (utils.c:773)
==28534== by 0x81A0526: init (ad_ffmpeg.c:56)
==28534== by 0x80E2B92: init_audio (dec_audio.c:95)
==28534== by 0x80E2F88: init_best_audio_codec (dec_audio.c:270)
==28534== by 0x8077F38: reinit_audio_chain (mplayer.c:1585)
==28534== by 0x8079931: main (mplayer.c:3583)
==28534== LEAK SUMMARY:
==28534== definitely lost: 10 bytes in 1 blocks.
==28534== possibly lost: 0 bytes in 0 blocks.
==28534== still reachable: 32,908 bytes in 12 blocks.
==28534== suppressed: 0 bytes in 0 blocks.
==28534== Reachable blocks (those to which a pointer was found) are not shown.
==28534== To see them, rerun with: --leak-check=full --show-reachable=yes

This bug was found using the Zzuf fuzzer. It was found as part of the
SUPERB-TRUST 2008 project ( see ) and the
metafuzz project ( see, stack hash 3209625344 ).

Let me know if I can provide more information.

Change History (2)

comment:1 Changed 9 years ago by compn

  • Owner changed from r_togni@… to reimar

comment:2 Changed 9 years ago by reimar

  • Resolution set to worksforme
  • Status changed from new to closed

Seems to have been fixed at some point.

Note: See TracTickets for help on using tickets.