Re: confusing valgrind report about tuplestore+wrapper_handler (?) on 32-bit arm - Mailing list pgsql-hackers
| From | Ranier Vilela |
|---|---|
| Subject | Re: confusing valgrind report about tuplestore+wrapper_handler (?) on 32-bit arm |
| Date | |
| Msg-id | CAEudQAp8ubgN42D3YUiR26aa6r-89eHa4F+TKkjgiadO3Ebuag@mail.gmail.com Whole thread Raw |
| In response to | confusing valgrind report about tuplestore+wrapper_handler (?) on 32-bit arm (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
| Responses |
Re: confusing valgrind report about tuplestore+wrapper_handler (?) on 32-bit arm
|
| List | pgsql-hackers |
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:
" 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
pgsql-hackers by date: