From: | Tomas Vondra <tomas(at)vondra(dot)me> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: strange valgrind reports about wrapper_handler on 64-bit arm |
Date: | 2025-03-09 17:11:05 |
Message-ID: | c877ef33-3a7a-4aad-a818-96e12810a7b3@vondra.me |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2025-03-09 17:23:55 | Re: BackgroundPsql swallowing errors on windows |
Previous Message | Jeff Davis | 2025-03-09 17:00:35 | Re: Statistics Import and Export |