Re: confusing valgrind report about tuplestore+wrapper_handler (?) on 32-bit arm - Mailing list pgsql-hackers
From | Tomas Vondra |
---|---|
Subject | Re: confusing valgrind report about tuplestore+wrapper_handler (?) on 32-bit arm |
Date | |
Msg-id | 6cf915d8-baec-4a74-b5a2-4f0533417435@enterprisedb.com Whole thread Raw |
In response to | Re: confusing valgrind report about tuplestore+wrapper_handler (?) on 32-bit arm (Ranier Vilela <ranier.vf@gmail.com>) |
Responses |
Re: confusing valgrind report about tuplestore+wrapper_handler (?) on 32-bit arm
|
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. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: