Hi,
On 2023-02-18 13:56:38 +0100, Tomas Vondra wrote:
> or (somewhat weird)
>
> ==23734== Use of uninitialised value of size 4
> ==23734== at 0x88DDC8: handle_sig_alarm (timeout.c:457)
> ==23734== by 0xFFFFFFFF: ???
> ==23734== Uninitialised value was created by a stack allocation
> ==23734== at 0x64CE2C: EndCommand (dest.c:167)
> ==23734==
> {
> <insert_a_suppression_name_here>
> Memcheck:Value4
> fun:handle_sig_alarm
> obj:*
> }
I'd try using valgrind's --vgdb-error=1, and inspecting the state.
I assume this is without specifying --read-var-info=yes? Might be worth
trying, sometimes the increased detail can be really helpful.
It's certainly interesting that the error happens in timeout.c:457 - currently
that's the end of the function. And dest.c:167 is the entry of EndCommand().
Perhaps there's some confusion around the state of the stack? The fact that it
looks like the function epilogue of handle_sig_alarm() uses an uninitialized
variable created by the function prologue of EndCommand() does seem to suggest
something like that.
It'd be interesting to see the exact instruction triggering the failure +
surroundings.
> It might be a valgrind issue and/or false positive, but I don't think
> I've seen such failures before, so I'm wondering if this might be due to
> some recent changes?
Have you run 32bit arm valgrind before? It'd not surprise me if there are some
32bit arm issues in valgrind, libc, or such.
Greetings,
Andres Freund
