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

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема confusing valgrind report about tuplestore+wrapper_handler (?) on 32-bit arm
Дата
Msg-id f1a022e5-9bec-42c5-badd-cfc00b60515c@enterprisedb.com
обсуждение исходный текст
Ответы Re: confusing valgrind report about tuplestore+wrapper_handler (?) on 32-bit arm
Список pgsql-hackers
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? But
also, at the same time, it's rather weird, because the report says it's
this bit in pqsignal.c

    (*pqsignal_handlers[postgres_signal_arg]) (postgres_signal_arg);

but it also says the memory was allocated in tuplestore, and that's
obviously very unlikely, because it does not do anything with signals.

I've only seen this once, but if it's related to signals, that's not
surprising - the window may be pretty narrow.

Anyone saw/investigated a report like this?


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: DROP OWNED BY fails to clean out pg_init_privs grants
Следующее
От: V N G Samba Siva Reddy Chinta
Дата:
Сообщение: Custom TupleTableSlotOps while Initializing Custom Scan