Re: valgrind error

On Fri, Jun 05, 2020 at 12:17:54PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > I can reproduce this on a 2017-vintage CPU with ./configure
> > ... USE_SLICING_BY_8_CRC32C=1 and then running "make installcheck-parallel"
> > under valgrind-3.15.0 (as packaged by RHEL 7.8).  valgrind.supp has a
> > suppression for CRC calculations, but it didn't get the memo when commit
> > 4f700bc renamed the function.  The attached patch fixes the suppression.
> 
> I can also reproduce this, on RHEL 8.2 which likewise has valgrind-3.15.0,
> using the same configuration to force use of that CRC function.  I concur
> with your diagnosis that this is just a missed update of the pre-existing
> suppression rule.  However, rather than
> 
> -       fun:pg_comp_crc32c
> +       fun:pg_comp_crc32c*
> 
> as you have it, I'd prefer to use
> 
> -       fun:pg_comp_crc32c
> +       fun:pg_comp_crc32c_sb8
> 
> which precisely matches what 4f700bc did.  The other way seems like
> it's giving a free pass to problems that could lurk in unrelated CRC
> implementations.

The undefined data is in the CRC input, namely the padding bytes in xl_*
structs.  Apparently, valgrind-3.15.0 doesn't complain about undefined input
to _mm_crc32_u* functions.  We should not be surprised if Valgrind gains the
features necessary to complain about the other implementations.

Most COMP_CRC32C callers don't have a suppression, so Valgrind still studies
each CRC implementation via those other callers.