[FFmpeg-devel] [PATCH] fate-valgrind.supp: Suppress uninitialized warnings for h264.
michaelni at gmx.at
Fri Feb 17 20:44:10 CET 2012
On Fri, Feb 17, 2012 at 06:20:11PM +0100, Reimar Döffinger wrote:
> On Fri, Feb 17, 2012 at 06:06:42PM +0100, Michael Niedermayer wrote:
> > > > > Option 1) Fix the uninitialized data source
> > theres not really a uninitialized data source
> Which you did not say, neither the message nor the patch itself
> contained any hint that you investigated this at all nor
> what the conclusions are.
> I still don't think it a great idea to reduce the usefulness
> of the whole valgrind test for those "few" failing ones,
> but after finding the cause, fine.
> But only with _proper_ documentation what this is about.
> And possibly a bug report to valgrind - I am not sure
> they will want to fix it, but there is a chance that they
> just forgot about the redzone special-case when porting the
> code from x86 to x86_64.
> > > > > Option 3) Add those suppressions only for the files with the issue
> > > >
> > > > Might be the quickest, smuggle a $TEST_VG_OPTS into the generated
> > > > valgrind command-line and have those tests set that variable.
> > > > (will still need some time/fiddling to get working I'm sure)
> > sounds like hacks that noone will maintain
> Well, it would offer a solution to the no-undef FATE test not being
> able to use --valgrind (though I actually think that is not true,
> it should be able to use --valgrind='valgrind --undef-value-errors=no').
I found a better solution to this issue
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel