From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: occasional valgrind reports for handle_sig_alarm on 32-bit ARM |
Date: | 2023-02-18 21:12:05 |
Message-ID: | 20230218211205.mzhkb4guqhwmtkti@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-02-18 21:15:22 | Re: Weird failure with latches in curculio on v15 |
Previous Message | Justin Pryzby | 2023-02-18 20:42:21 | Re: Reducing connection overhead in pg_upgrade compat check phase |