public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tomas Vondra <[email protected]>
To: Andres Freund <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Nathan Bossart <[email protected]>
Subject: Re: strange valgrind reports about wrapper_handler on 64-bit arm
Date: Sat, 8 Mar 2025 21:38:52 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <i73pjuqcqgv5lsprc76z4bug55okadxpzpuijnup34qmqtwexi@gakdkcyjox5l>
References: <[email protected]>
<i73pjuqcqgv5lsprc76z4bug55okadxpzpuijnup34qmqtwexi@gakdkcyjox5l>
On 3/7/25 17:32, Andres Freund wrote:
> Hi,
>
> On 2025-03-07 00:03:47 +0100, Tomas Vondra wrote:
>> while running check-world on 64-bit arm (rpi5 with Debian 12.9), I got a
>> couple reports like this:
>>
>> ==64550== Use of uninitialised value of size 8
>> ==64550== at 0xA62FE0: wrapper_handler (pqsignal.c:107)
>> ==64550== by 0x580BB9E7: ??? (in
>> /usr/libexec/valgrind/memcheck-arm64-linux)
>> ==64550== Uninitialised value was created by a stack allocation
>> ==64550== at 0x4F94660: strcoll_l (strcoll_l.c:258)
>> ==64550==
>> {
>> <insert_a_suppression_name_here>
>> Memcheck:Value8
>> fun:wrapper_handler
>> obj:/usr/libexec/valgrind/memcheck-arm64-linux
>> }
>> **64550** Valgrind detected 1 error(s) during execution of "ANALYZE
>> mcv_lists;"
>
>> The exact command varies, I don't think it's necessarily about analyze
>> or extended stats.
>
> Do you have a few other examples from where it was triggered?
>
> Is the source of the uninitialized value always strcoll_l?
>
I've seen a couple reports, but only a single one had info about source
of the allocation (and that was strcoll).
> Can you reliably reproduce it in certain scenarios or is it probabilistic in
> some form?
>
I believe it's probabilistic, I certainly don't know how to trigger or
reproduce it.
> Do you know what signal was delivered (I think that could be detected using
> valgrinds --vgdb)?
>
No idea.
>
>> The line the report refers to is this:
>>
>> (*pqsignal_handlers[postgres_signal_arg]) (postgres_signal_arg);
>>
>> so I guess it can't be about postgres_signal_arg (as that's an int). But
>> that leaves just pqsignal_handlers, and why would that be uninitialized?
>
> Is it possible that the signal number we're getting called for is above
> PG_NSIG? That'd explain why the source value is something fairly random?
>
No idea.
> ISTM that we should add an Assert() to wrapper_handler() that ensures that the
> signal arg is below PG_NSIG.
>
No idea.
>
> Might also be worth trying to run without valgrind but with address and
> undefined behaviour sanitizers enabled. I don't currently have access to an
> armv8 machine that's not busy doing other stuff...
>
I've restarted check-world with valgrind on my rpi5 machines, with
current master. I can try running other stuff once that finishes in a
couple hours.
regards
--
Tomas Vondra
view thread (13+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: strange valgrind reports about wrapper_handler on 64-bit arm
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox