[Libav-user] Closing codec properly after an audio decoding

Polochon Street polochonstreet at gmx.fr
Sun Aug 30 17:55:17 CEST 2015


Sorry for answering my own mail, but I've been finally able to obtain a 
full trace, thanks to --disable-stripping and some options of a PKGBUILD:

==3250== 4,793 (24 direct, 4,769 indirect) bytes in 1 blocks are 
definitely lost in loss record 235 of 237
==3250==    at 0x4C2AED6: memalign (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3250==    by 0x4C2AFF1: posix_memalign (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3250==    by 0x554442F: av_malloc (mem.c:97)
==3250==    by 0x55445FD: av_mallocz (mem.c:254)
==3250==    by 0x5533DED: av_buffer_ref (buffer.c:94)
==3250==    by 0x5281FF2: avformat_queue_attached_pictures (utils.c:395)
==3250==    by 0x528C767: avformat_open_input (utils.c:486)
==3250==    by 0x4021DD: audio_decode (decode.c:23)
==3250==    by 0x4019F7: analyze (analyze.c:30)
==3250==    by 0x401865: main (gui_dummy.c:24)

It seems that I'm not freeing all of my AVFormatCtx streams properly, 
but I'm using avformat_close_input(&pFormatCtx) and 
avformat_free_context(pFormatCtx), am I missing something?

Le 29/08/2015 20:40, Polochon Street a écrit :
> Okay, so I compiled ffmpeg with those flags:
> /configure            \
>     --prefix=/usr        \
>     --shlibdir=/usr/lib  \
>     --disable-static \
>     --enable-debug=3 \
>     --disable-optimizations \
>     --disable-stripping \
>     --enable-gpl         \
>     --enable-gnutls      \
>     --enable-libass      \
>     --enable-libfdk-aac  \
>     --enable-libfreetype \
>     --enable-libmp3lame  \
>     --enable-libopus     \
>     --enable-libtheora   \
>     --enable-libvorbis   \
>     --enable-libvpx      \
>     --enable-libx264     \
>     --enable-libx265     \
>     --enable-nonfree     \
>     --enable-shared      \
>     --enable-x11grab     \
> And I cmake'd my program with -DCMAKE_BUILD_TYPE=Debug 
> -DCMAKE_C_FLAGS=-fsanitize=address, but I still only have this debug 
> trace:
>
> ==17320==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 664 byte(s) in 2 object(s) allocated from:
>     #0 0x7f5aaf43e386 in __interceptor_posix_memalign 
> /build/gcc-multilib/src/gcc-5.2.0/libsanitizer/asan/asan_malloc_linux.cc:105
>     #1 0x7f5aaea93b0f in av_malloc (/usr/lib/libavutil.so.54+0x1db0f)
>
> Indirect leak of 4769 byte(s) in 2 object(s) allocated from:
>     #0 0x7f5aaf43e386 in __interceptor_posix_memalign 
> /build/gcc-multilib/src/gcc-5.2.0/libsanitizer/asan/asan_malloc_linux.cc:105
>     #1 0x7f5aaea93b0f in av_malloc (/usr/lib/libavutil.so.54+0x1db0f)
>
> SUMMARY: AddressSanitizer: 5433 byte(s) leaked in 4 allocation(s).
>
> The 29/08/2015 17:10, Carl Eugen Hoyos wrote:
>> //First step (that is practically always sufficient)
>> is to find out where exactly (!) the memory was
>> allocated: We all know that it was inside mem.c
>> but the important question is what called
>> av_malloc().
>> Either use a static binary or use
>> --disable-stripping for a useful debug build.
>>
>> Carl Eugen
>
>
>
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20150830/cd2a2c9e/attachment.html>


More information about the Libav-user mailing list