Re: confusing valgrind report about tuplestore+wrapper_handler (?) on 32-bit arm - Mailing list pgsql-hackers

On 6/20/24 13:32, Ranier Vilela wrote:
> Em qui., 20 de jun. de 2024 às 07:28, Tomas Vondra <
> tomas.vondra@enterprisedb.com> escreveu:
>
>> Hi,
>>
>> While running valgrind on 32-bit ARM (rpi5 with debian), I got this
>> really strange report:
>>
>>
>> ==25520== Use of uninitialised value of size 4
>> ==25520==    at 0x94A550: wrapper_handler (pqsignal.c:108)
>> ==25520==    by 0x4D7826F: ??? (sigrestorer.S:64)
>> ==25520==  Uninitialised value was created by a heap allocation
>> ==25520==    at 0x8FB780: palloc (mcxt.c:1340)
>> ==25520==    by 0x913067: tuplestore_begin_common (tuplestore.c:289)
>> ==25520==    by 0x91310B: tuplestore_begin_heap (tuplestore.c:331)
>> ==25520==    by 0x3EA717: ExecMaterial (nodeMaterial.c:64)
>> ==25520==    by 0x3B2FF7: ExecProcNodeFirst (execProcnode.c:464)
>> ==25520==    by 0x3EF73F: ExecProcNode (executor.h:274)
>> ==25520==    by 0x3F0637: ExecMergeJoin (nodeMergejoin.c:703)
>> ==25520==    by 0x3B2FF7: ExecProcNodeFirst (execProcnode.c:464)
>> ==25520==    by 0x3C47DB: ExecProcNode (executor.h:274)
>> ==25520==    by 0x3C4D4F: fetch_input_tuple (nodeAgg.c:561)
>> ==25520==    by 0x3C8233: agg_retrieve_direct (nodeAgg.c:2364)
>> ==25520==    by 0x3C7E07: ExecAgg (nodeAgg.c:2179)
>> ==25520==    by 0x3B2FF7: ExecProcNodeFirst (execProcnode.c:464)
>> ==25520==    by 0x3A5EC3: ExecProcNode (executor.h:274)
>> ==25520==    by 0x3A8FBF: ExecutePlan (execMain.c:1646)
>> ==25520==    by 0x3A6677: standard_ExecutorRun (execMain.c:363)
>> ==25520==    by 0x3A644B: ExecutorRun (execMain.c:304)
>> ==25520==    by 0x6976D3: PortalRunSelect (pquery.c:924)
>> ==25520==    by 0x6972F7: PortalRun (pquery.c:768)
>> ==25520==    by 0x68FA1F: exec_simple_query (postgres.c:1274)
>> ==25520==
>> {
>>    <insert_a_suppression_name_here>
>>    Memcheck:Value4
>>    fun:wrapper_handler
>>    obj:/usr/lib/arm-linux-gnueabihf/libc.so.6
>> }
>> **25520** Valgrind detected 1 error(s) during execution of "select
>> count(*) from
>> **25520**   (select * from tenk1 x order by x.thousand, x.twothousand,
>> x.fivethous) x
>> **25520**   left join
>> **25520**   (select * from tenk1 y order by y.unique2) y
>> **25520**   on x.thousand = y.unique2 and x.twothousand = y.hundred and
>> x.fivethous = y.unique2;"
>>
>>
>> I'm mostly used to weird valgrind stuff on this platform, but it's
>> usually about libarmmmem and (possibly) thinking it might access
>> undefined stuff when calculating checksums etc.
>>
>> This seems somewhat different, so I wonder if it's something real?
>
> It seems like a false positive to me.
>
> According to valgrind's documentation:
> https://valgrind.org/docs/manual/mc-manual.html#mc-manual.value
>
> " This can lead to false positive errors, as the shared memory can be
> initialised via a first mapping, and accessed via another mapping. The
> access via this other mapping will have its own V bits, which have not been
> changed when the memory was initialised via the first mapping. The bypass
> for these false positives is to use Memcheck's client requests
> VALGRIND_MAKE_MEM_DEFINED and VALGRIND_MAKE_MEM_UNDEFINED to inform
> Memcheck about what your program does (or what another process does) to
> these shared memory mappings. "
>

But that's about shared memory, and the report has nothing to do with
shared memory AFAICS.