[FFmpeg-devel] [PATCH] Fix uninitialized reads for fate-vsynth1-asv2 test.
Reimar.Doeffinger at gmx.de
Mon Jan 16 00:13:16 CET 2012
On Sun, Jan 15, 2012 at 02:21:43PM +0100, Clément Bœsch wrote:
> On Sun, Jan 15, 2012 at 01:57:07PM +0100, Reimar Döffinger wrote:
> > On Sun, Jan 15, 2012 at 01:10:00PM +0100, Michael Niedermayer wrote:
> > > On Sun, Jan 15, 2012 at 11:04:23AM +0100, Reimar Döffinger wrote:
> > > > This is not a real error and memsetting always even when the
> > > > size did not change is overkill, but I'd still like to propose
> > > > this.
> > > >
> > > > Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> > >
> > > should do no harm, thus ok
> > Pushed.
> > Let's see how far a full valgrind run (with uninitialized reads not
> > disabled).
> > Zlib init function seems broken, so I needed a suppression file for that
> > already.
> > I see the valgrind fate also has a custom suppression file.
> > Maybe we should collect these and add a valgrind suppression file into
> > git?
> The current suppression file is the following:
> % cat fate/eval-strtod.supp
> This helps masking this issue: http://sourceware.org/bugzilla/show_bug.cgi?id=12424
Interesting, I don't get that on debian unstable, though I suspect
it's probably not a bug but just something that should go into
valgrind's default suppression file (seems to me it is not yet, even in
> I don't know if lavf-mxf is the blocking the rest of the tests, but we
> should be fixed "soon" if you're last patch goes upstream.
Well, who knows what breaks in those last 100, didn't get that far yet on
my machine (also because "make fate -j5" didn't seem to work, that makes
things a lot slower).
> About the current uninit read the current patch is fixing, it should be
> ignored with --undef-value-errors=no (it's slow enough so I disabled
I know FATE does not test it, but that's not a reason to ignore those.
More information about the ffmpeg-devel