Re: suspicious valgrind reports about radixtree/tidstore on arm64

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, John Naylor <johncnaylorls(at)gmail(dot)com>
Subject: Re: suspicious valgrind reports about radixtree/tidstore on arm64
Date: 2024-06-20 15:33:46
Message-ID: 353044.1718897626@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> writes:
> Em qua., 19 de jun. de 2024 às 20:52, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escreveu:
>> 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?

Dunno, I only saw valgrind complaints in local_ts_node_16_search_eq,
and Tomas reported the same.

It seems moderately likely to me that this is a bug in aarch64
valgrind. Still, if it is that then people will have to deal with it
for awhile yet. It won't cost us anything meaningful to work around
it (he says, without having done actual measurements...)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-06-20 15:35:13 Re: DROP OWNED BY fails to clean out pg_init_privs grants
Previous Message Andreas Karlsson 2024-06-20 15:25:06 Re: Special-case executor expression steps for common combinations