From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
Subject: | Re: ubsan fails on 32bit builds |
Date: | 2022-11-17 07:28:21 |
Message-ID: | 20221117072821.5xufyalfyc2bml6o@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-11-16 17:42:30 -0800, Andres Freund wrote:
> Afaict the problem is that
> proc = (PGPROC *) &(waitQueue->links);
>
> is a gross gross hack - this isn't actually a PGPROC, it's pointing to an
> SHM_QUEUE, but *not* one embedded in PGPROC. It kinda works because ->links
> is at offset 0 in PGPROC, which means that
> SHMQueueInsertBefore(&(proc->links), &(MyProc->links));
> will turn &proc->links back into waitQueue->links. Which we then can enqueue
> again.
>
> I don't see the point of this hack, even leaving ubsan's valid complaints
> aside. Why bother having this, sometimes, fake PGPROC pointer when we could
> just use a SHM_QUEUE* to determine the insertion point?
As done in the attached patch. With this ubsan passes both on 32bit and 64bit.
Greetings,
Andres Freund
Attachment | Content-Type | Size |
---|---|---|
0001-Fix-mislabeling-of-PROC_QUEUE-links-as-PGPROC-fixing.patch | text/x-diff | 3.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-11-17 07:28:27 | Re: Assertion failure with barriers in parallel hash join |
Previous Message | Maciek Sakrejda | 2022-11-17 07:26:09 | Odd behavior with pg_stat_statements and queries called from SQL functions |