I was just trying to revive lousyjack, my valgrind buildfarm animal
which has been offline for 12 days, after having upgraded the machine
(fedora 31, gcc 9.3.1, valgrind 3.15) and noticed lots of errors like this:
2020-04-17 19:26:03.483 EDT [63741:3] pg_regress LOG: statement: CREATE
DATABASE
On 4/18/20 9:15 AM, Andrew Dunstan wrote:
> I was just trying to revive lousyjack, my valgrind buildfarm animal
> which has been offline for 12 days, after having upgraded the machine
> (fedora 31, gcc 9.3.1, valgrind 3.15) and noticed lots of errors like this:
>
>
> 2020-04-17 19:26:03.483 EDT [
On Sun, May 10, 2020 at 09:29:05AM -0400, Andrew Dunstan wrote:
> On 4/18/20 9:15 AM, Andrew Dunstan wrote:
> > I was just trying to revive lousyjack, my valgrind buildfarm animal
> > which has been offline for 12 days, after having upgraded the machine
> > (fedora 31, gcc 9.3.1, valgrind 3.15) and
Noah Misch 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
On Fri, Jun 05, 2020 at 12:17:54PM -0400, Tom Lane wrote:
> Noah Misch 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
>
Noah Misch writes:
> On Fri, Jun 05, 2020 at 12:17:54PM -0400, Tom Lane wrote:
>> 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 cou
I wrote:
> Noah Misch writes:
>> 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.
> Perhaps it already has ... I wonder if anyone's
My Valgrind test script reports the following error, triggered from
within contrib/bloom's regression test suite on master as of right
now:
""
2019-09-27 20:53:50.910 PDT 9740 DEBUG: building index "bloomidx" on
table "tst" serially
2019-09-27 20:53:51.049 PDT 9740 DEBUG: CommitTransaction(1
On Fri, Sep 27, 2019 at 09:02:34PM -0700, Peter Geoghegan wrote:
> My Valgrind test script reports the following error, triggered from
> within contrib/bloom's regression test suite on master as of right
> now:
>
> I suspect that the recent commit 69f94108 is involved here, but I
> haven't confirm
memory
UNDEFINED. If this memory was already allocated and initialized, it's
expected
to be DEFINED. So it can cause false valgrind error reports. I fixed it in
0001
patch.
Also, it took me a while to understand what's going on there, so in 0002
patch
I tried to improve comments and renamed
emory behind the new allocated
> memory
> UNDEFINED. If this memory was already allocated and initialized, it's
> expected
> to be DEFINED. So it can cause false valgrind error reports. I fixed it in
> 0001 patch.
Hmm, I see the concern: adjusting the Valgrind marking of bytes
Thank you, I moved comment changes to 0001 and rewrote the fix through Min().
> The first hunk in 0001 doesn't seem quite right yet:
>
> * old allocation.
> */
> #ifdef USE_VALGRIND
> -if (oldsize > chunk->requested_size)
> +if (size > chunk->requested_size &&
Karina Litskevich writes:
> Thank you, I moved comment changes to 0001 and rewrote the fix through Min().
Looks good. I pushed it after a little more fiddling with the comments.
Thanks for the report and patch!
regards, tom lane
13 matches
Mail list logo
