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 <jamr...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
