Re: strange valgrind reports about wrapper_handler on 64-bit arm

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