Re: suspicious valgrind reports about radixtree/tidstore on arm64
| От | Ranier Vilela |
|---|---|
| Тема | Re: suspicious valgrind reports about radixtree/tidstore on arm64 |
| Дата | |
| Msg-id | CAEudQArCRwOjTz3-46YwJU3Ci3RtsOEMVSHFa8YmUJLGTpnTEQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: suspicious valgrind reports about radixtree/tidstore on arm64 (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: suspicious valgrind reports about radixtree/tidstore on arm64
|
| Список | 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 по дате отправления: