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

Em qui., 20 de jun. de 2024 às 07:28, Tomas Vondra <
tomas(dot)vondra(at)enterprisedb(dot)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. "

best regards,
Ranier Vilela