[FFmpeg-devel] [PATCH 1/2] avformat/mov: zero initialize codec_name in mov_parse_stsd_video()

[James Almer]

On 10/20/2016 3:25 PM, Andreas Cadhalpun wrote:
> On 20.10.2016 03:25, Michael Niedermayer wrote:
>> On Wed, Oct 19, 2016 at 07:30:29PM +0200, Andreas Cadhalpun wrote:
>>> On 19.10.2016 04:15, James Almer wrote:
>>>> On 10/17/2016 9:57 PM, Michael Niedermayer wrote:
>>>>> On Sun, Oct 16, 2016 at 09:34:50PM -0300, James Almer wrote:
>>>>>> Fixes valgrind warning about "Conditional jump or move depends on uninitialised value(s)"
>>>>>>
>>>>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>>>>> ---
>>>>>>  libavformat/mov.c | 2 +-
>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> This should be suppressable by adding it to
>>>>> tests/fate-valgrind.supp
>>>>
>>>> I'll leave that to someone else. No idea how to add stuff to that file.
>>>>
>>>> Should i drop this patch? Zero initializing a buffer in stack wouldn't
>>>> hurt IMO.
>>>
>>> I prefer fixing such things in the code if it's reasonable possible, which
>>> is the case here. In other words, the patch looks good to me.
>>
>> I think the bug is that valgrind misinterprets highly optimized libc/gcc
>> code, i might be wrong though as i didnt disassemble and analyze this,
>> that was just my feeling ...
>> But if true a change to ffmpeg can only workaround but not fix this
> 
> Yes, this seems to be a false positive. But working around it is good, because
> it increases the signal to noise ratio of valgrind.
> This is similar to false positive compiler warnings: Not working around them
> has high chances of wasting the time of the next one to look into it.
> 
> Best regards,
> Andreas

Pushed. Three tests were failing now because of this, up from one when i
first submitted this patch, so even as a workaround it still gets rid of
the noise and will make new actual leaks or overreads easily noticeable.

Anyone wanting to fix this by adding a suppression or by fixing Valgrind
is welcome.