[Libav-user] stubborn valgrind issue

[Brian Lewis]

On 2013.07.31, at 09:15, Carl Eugen Hoyos wrote:
> (valgrind output missing.)

==7895== Memcheck, a memory error detector
==7895== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==7895== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==7895== Command: ./test
==7895==
==7895== Use of uninitialised value of size 8
==7895==    at 0x839BDBC: crc32 (in /usr/lib/libz.so.1.2.8)
==7895==    by 0x51B02B3: ??? (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x51B0C6F: ??? (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x525EC75: avcodec_encode_video2 (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x40113A: main (test.c:98)
==7895==
==7895== Use of uninitialised value of size 8
==7895==    at 0x839BDCB: crc32 (in /usr/lib/libz.so.1.2.8)
==7895==    by 0x51B02B3: ??? (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x51B0C6F: ??? (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x525EC75: avcodec_encode_video2 (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x40113A: main (test.c:98)
==7895==
==7895== Use of uninitialised value of size 8
==7895==    at 0x839BDD2: crc32 (in /usr/lib/libz.so.1.2.8)
==7895==    by 0x51B02B3: ??? (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x51B0C6F: ??? (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x525EC75: avcodec_encode_video2 (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x40113A: main (test.c:98)
==7895==
==7895== Use of uninitialised value of size 8
==7895==    at 0x839BE0F: crc32 (in /usr/lib/libz.so.1.2.8)
==7895==    by 0x51B02B3: ??? (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x51B0C6F: ??? (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x525EC75: avcodec_encode_video2 (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x40113A: main (test.c:98)
==7895==
### packet size: 356047
==7895== Syscall param write(buf) points to uninitialised byte(s)
==7895==    at 0x65741D0: __write_nocancel (in /usr/lib/libc-2.17.so)
==7895==    by 0x40119F: main (test.c:102)
==7895==  Address 0xbef3efb is 356,027 bytes inside a block of size 356,063 alloc'd
==7895==    at 0x4C29B66: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7895==    by 0x4C29C57: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7895==    by 0x602C5AC: av_malloc (in /usr/lib/libavutil.so.52.18.100)
==7895==    by 0x4F13AB8: ??? (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x4F13EBC: av_dup_packet (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x525EE2B: avcodec_encode_video2 (in /usr/lib/libavcodec.so.54.92.100)
==7895==    by 0x40113A: main (test.c:98)

> > int buf_size = avpicture_get_size(PIX_FMT_OUT, WIDTH, HEIGHT);
> > uint8_t *buf = malloc(buf_size);
>
> Does it get better if you allocate more memory?
> (FF_INPUT_BUFFER_PADDING_SIZE)

No, same problem. I tried malloc'ing buf_size + {1,10,100,1000} *
FF_INPUT_BUFFER_PADDING_SIZE.

> On some (broken) platforms, you have to use av_malloc() to ensure
> sufficient alignment.

I replaced all my mallocs with av_mallocs, but it didn't seem to help.
Thanks for getting back to me.