| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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:52:10 |
| Message-ID: | Z8skOiYFFNzbPVED@nathan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 07, 2025 at 11:41:38AM -0500, Andres Freund wrote:
> 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.
Good enough for me. I'll commit/back-patch to v17 the attached soon.
--
nathan
| Attachment | Content-Type | Size |
|---|---|---|
| assert.patch | text/plain | 293 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2025-03-07 16:53:29 | Re: Statistics Import and Export |
| Previous Message | Navneet Kumar | 2025-03-07 16:47:41 | Re: support virtual generated column not null constraint |