| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(at)vondra(dot)me>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: strange valgrind reports about wrapper_handler on 64-bit arm |
| Date: | 2025-03-07 16:41:38 |
| Message-ID: | 77dxan5ga3rjxjbnm2vtljntbcpab3wov2zlcdukw75a2qojmu@3mbkzfpv54sd |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2025-03-07 10:36:35 -0600, Nathan Bossart wrote:
> On Fri, Mar 07, 2025 at 11:32:28AM -0500, Andres Freund wrote:
> > 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?
> >
> > ISTM that we should add an Assert() to wrapper_handler() that ensures that the
> > signal arg is below PG_NSIG.
>
> We have such an assertion in pqsignal() before we install wrapper_handler
> for anything. Is there another way it could be getting called with a
> different signo?
Who the hell knows :).
One potential way would be that we got SIGNAL_ARGS wrong for the platform and
are interpreting some random thing as the signal number. Or something went
wrong in the windows signal emulation code. Or ...
It seems cheap insurance to add it both places.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-03-07 16:42:35 | Re: Commitfest app release on Feb 17 with many improvements |
| Previous Message | Alexander Korotkov | 2025-03-07 16:39:42 | Re: pg_atomic_compare_exchange_*() and memory barriers |