Re: suspicious valgrind reports about radixtree/tidstore on arm64 - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: suspicious valgrind reports about radixtree/tidstore on arm64
Date
Msg-id CAEudQArCRwOjTz3-46YwJU3Ci3RtsOEMVSHFa8YmUJLGTpnTEQ@mail.gmail.com
Whole thread Raw
In response to Re: suspicious valgrind reports about radixtree/tidstore on arm64  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: suspicious valgrind reports about radixtree/tidstore on arm64
List pgsql-hackers
Em qua., 19 de jun. de 2024 às 20:52, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
I wrote:
> I hypothesize that the reason we're not seeing equivalent failures
> on x86_64 is one of

> 1. x86_64 valgrind is stupider than aarch64, and fails to track that
> the contents of the SIMD registers are only partially defined.

> 2. x86_64 valgrind is smarter than aarch64, and is able to see
> that the "mask off invalid entries" step removes all the
> potentially-uninitialized bits.

Hah: it's the second case.  If I patch radixtree.h as attached,
then x86_64 valgrind complains about

==00:00:00:32.759 247596== Conditional jump or move depends on uninitialised value(s)
==00:00:00:32.759 247596==    at 0x52F668: local_ts_node_16_search_eq (radixtree.h:1018)

showing that it knows that the result of vector8_highbit_mask is
only partly defined.
I wouldn't be surprised if *RT_NODE_16_GET_INSERTPOS* (src/include/lib/radixtree.h),
does not suffer from the same problem?
Even with Assert trying to protect.

Does the fix not apply here too?

best regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Conflict Detection and Resolution
Next
From: Tomas Vondra
Date:
Subject: Re: confusing valgrind report about tuplestore+wrapper_handler (?) on 32-bit arm