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