Tom Lane wrote:
>>==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.
>
Anything asking valgrind to give more stack output might help?
> valgrind's habit of propagating
>undef'ness through copies isn't real helpful here.
>
>
Well, considering the amount of false-positives you would get if you
didn't.......
If I understand this correctly, that was a real bug there, wasn't it?
>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.
>
>
You might want to report that to their bugs list. My browsing the docs
just now leads me to believe valgrind is, generally, aware that only
parts of a word can be uninitialized. You can even set it to report it
at the point where uninitialized and initialized data are merged into a
single operation.
In fact, that may help with getting the errors closer to the place where
the actual problem resides. Then again, it may cause it to generate way
more false positives.
--
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/