Re: strange valgrind reports about wrapper_handler on 64-bit arm - Mailing list pgsql-hackers
From | Tomas Vondra |
---|---|
Subject | Re: strange valgrind reports about wrapper_handler on 64-bit arm |
Date | |
Msg-id | c877ef33-3a7a-4aad-a818-96e12810a7b3@vondra.me Whole thread Raw |
In response to | Re: strange valgrind reports about wrapper_handler on 64-bit arm (Nathan Bossart <nathandbossart@gmail.com>) |
List | pgsql-hackers |
On 3/9/25 03:16, Nathan Bossart wrote: > On Sat, Mar 08, 2025 at 11:48:22PM +0100, Tomas Vondra wrote: >> Shortly after restarting this I got three more reports - all of them are >> related to strcoll_l. This is on c472a18296e4, i.e. with the asserts >> added in this thread etc. But none of those seem to fail. > >> ==189168== at 0xA683CC: wrapper_handler (pqsignal.c:90) >> ==189168== at 0xA683F0: wrapper_handler (pqsignal.c:91) >> ==189168== at 0xA684D4: wrapper_handler (pqsignal.c:110) > > This appears to refer to the following lines: > > Assert(postgres_signal_arg > 0); > Assert(postgres_signal_arg < PG_NSIG); > (*pqsignal_handlers[postgres_signal_arg]) (postgres_signal_arg); > > The common ingredient seems to be postgres_signal_arg. I haven't found > anything else that seems helpful. > Yeah, it's a bit weird. I got another report on the 64-bit rpi5 machine (except for the command it's exactly the same), and then also this report on the 32-bit machine: --------------------------------------------------------------- ==3482== Use of uninitialised value of size 4 ==3482== at 0x991498: wrapper_handler (pqsignal.c:113) ==3482== by 0xFFFFFFFF: ??? ==3482== Uninitialised value was created by a heap allocation ==3482== at 0x940EB8: palloc (mcxt.c:1341) ==3482== by 0x980037: initStringInfoInternal (stringinfo.c:45) ==3482== by 0x980103: initStringInfo (stringinfo.c:99) ==3482== by 0x7194B7: ReadArrayStr (arrayfuncs.c:613) ==3482== by 0x718803: array_in (arrayfuncs.c:289) ==3482== by 0x90024F: InputFunctionCallSafe (fmgr.c:1607) ==3482== by 0x2E346B: CopyFromTextLikeOneRow (copyfromparse.c:1029) ==3482== by 0x2E304B: CopyFromTextOneRow (copyfromparse.c:919) ==3482== by 0x2E2EEF: NextCopyFrom (copyfromparse.c:890) ==3482== by 0x2DF5C7: CopyFrom (copyfrom.c:1149) ==3482== by 0x2DAE33: DoCopy (copy.c:306) ==3482== by 0x6CC38F: standard_ProcessUtility (utility.c:738) ==3482== by 0x4B654C3: pgss_ProcessUtility (pg_stat_statements.c:1179) ==3482== by 0x6CBBF3: ProcessUtility (utility.c:519) ==3482== by 0x6CA24B: PortalRunUtility (pquery.c:1184) ==3482== by 0x6CA537: PortalRunMulti (pquery.c:1348) ==3482== by 0x6C9837: PortalRun (pquery.c:819) ==3482== by 0x6C1BEB: exec_simple_query (postgres.c:1272) ==3482== by 0x6C74FF: PostgresMain (postgres.c:4693) ==3482== by 0x6BD297: BackendMain (backend_startup.c:107) ==3482== { <insert_a_suppression_name_here> Memcheck:Value4 fun:wrapper_handler obj:* } **3482** Valgrind detected 1 error(s) during execution of "COPY array_op_test FROM '/home/debian/postgres/src/test/regress/data/array.data';" --------------------------------------------------------------- This all seems very strange ... I'm starting to wonder if maybe this is a valgrind issue. Both machines have valgrind 3.19, I'll try with a custom build of 3.24 (the latest release). regards -- Tomas Vondra
pgsql-hackers by date: