Anything asking valgrind to give more stack output might help?==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 propagatingWell, considering the amount of false-positives you would get if you didn't.......
undef'ness through copies isn't real helpful here.
If I understand this correctly, that was a real bug there, wasn't it?
BTW, valgrind's report about "size 4" is actively misleading, becauseYou 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.
the only part of that struct that TupleDescInitEntry isn't careful to
set explicitly is a one-byte pad between attislocal and attinhcount.
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/
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
