Re: BUG #15899: Valgrind detects errors on create gist index

Hi,

On 2019-07-09 13:43:41 +0900, Michael Paquier wrote:
> On Sun, Jul 07, 2019 at 10:21:26PM +0300, Alexander Lakhin wrote:
> I can see that most of the complaints from valgrind go away, and I am
> still bumping into these two ones.
> ==14943== Conditional jump or move depends on uninitialised value(s)
> ==14943== at 0x1FD7A5: gistchoose (gistutil.c:535)
> ==14943== by 0x20B5BA: gistProcessItup (gistbuild.c:597)
> ==14943== by 0x20C367: gistProcessEmptyingQueue (gistbuild.c:973)
> ==14943== by 0x20C476: gistEmptyAllBuffers (gistbuild.c:1036)
> ==14943== by 0x20ACD9: gistbuild (gistbuild.c:207)
> ==14943== by 0x2DCDF9: index_build (index.c:2726)
> ==14943== by 0x2DA4CA: index_create (index.c:1177)
> ==14943== by 0x3C52BB: DefineIndex (indexcmds.c:1005)
> ==14943== by 0x653A27: ProcessUtilitySlow (utility.c:1373)
> ==14943== by 0x652AE0: standard_ProcessUtility (utility.c:927)
> ==14943== by 0x651B78: ProcessUtility (utility.c:360)
> ==14943== by 0x650AD7: PortalRunUtility (pquery.c:1175)
> ==14943== Uninitialised value was created by a stack allocation
> ==14943== at 0x4C6F3B0: ??? (in
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
> ==14943==
> ==14943== Conditional jump or move depends on uninitialised value(s)
> ==14943== at 0x1FD770: gistchoose (gistutil.c:513)
> ==14943== by 0x20B5BA: gistProcessItup (gistbuild.c:597)
> ==14943== by 0x20C367: gistProcessEmptyingQueue (gistbuild.c:973)
> ==14943== by 0x20C476: gistEmptyAllBuffers (gistbuild.c:1036)
> ==14943== by 0x20ACD9: gistbuild (gistbuild.c:207)
> ==14943== by 0x2DCDF9: index_build (index.c:2726)
> ==14943== by 0x2DA4CA: index_create (index.c:1177)
> ==14943== by 0x3C52BB: DefineIndex (indexcmds.c:1005)
> ==14943== by 0x653A27: ProcessUtilitySlow (utility.c:1373)
> ==14943== by 0x652AE0: standard_ProcessUtility (utility.c:927)
> ==14943== by 0x651B78: ProcessUtility (utility.c:360)
> ==14943== by 0x650AD7: PortalRunUtility (pquery.c:1175)
> ==14943== Uninitialised value was created by a stack allocation
> ==14943== at 0x4C6F3B0: ??? (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1)
>
> Still they don't make much sense, because these point to complaints
> that keep_current_best may have an uninitialized value, and this
> variable is initialized before scanning the tuples on the page. I
> would not have expected that an uninitialized thing from libcrypto
> stack would have an effect here, and we have the project policy to
> not silence stuff fro outside the tree as far as I know.

I think this is just that openssl bug we've been talking about a while
ago. keep_current_best is initialized via random(), which is in turn
initialized with openssl's randomness (cf InitProcessGlobals()). As
valgrind - legitimately - thinks that the openssl' random value is
tainted by uninitialized data, it thinks that keep_current_best is
uninitialized. And the branches above are the first values where a jump
is made based on that uninitialized data.

Greetings,

Andres Freund