Re: valgrind errors - Mailing list pgsql-hackers

From Tom Lane
Subject Re: valgrind errors
Date
Msg-id 8966.1082659048@sss.pgh.pa.us
Whole thread Raw
In response to valgrind errors  (Neil Conway <neilc@samurai.com>)
Responses Re: valgrind errors
List pgsql-hackers
Neil Conway <neilc@samurai.com> writes:
> Valgrind'ing the postmaster yields a fair number of errors. A lot of
> them are similar, such as the following:

> ==29929== Use of uninitialised value of size 4
> ==29929==    at 0x80AFB80: XLogInsert (xlog.c:570)

Oh, I see the issue.  Shachar is correct that valgrind doesn't complain
about copying uninitialized bytes.  But it *does* complain about adding
them into a CRC ... so what we are seeing here is gripes about including
padding bytes into a CRC, or writing them out in the case of the
complaints like this one:

> ==29929== Syscall param write(buf) contains uninitialised or
> unaddressable byte(s)

The original pad bytes may be fairly far removed from the point of the
error ... an example is that I was able to make one XLogInsert complaint
go away by changing palloc to palloc0 at tupdesc.c line 413 (in
TupleDescInitEntry), which is several memcpy's removed from the data
that gets passed to XLogInsert.  valgrind's habit of propagating
undef'ness through copies isn't real helpful here.

BTW, valgrind's report about "size 4" is actively misleading, because
the only part of that struct that TupleDescInitEntry isn't careful to
set explicitly is a one-byte pad between attislocal and attinhcount.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions
Next
From: Bruce Momjian
Date:
Subject: Re: License question