Re: Dereference before NULL check (src/backend/storage/ipc/latch.c) - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)
Date
Msg-id CA+hUKGLVsSxGCg7zGrukR8Gq8SAVoB7CR4RM0LRtqonO6THgcA@mail.gmail.com
Whole thread Raw
In response to Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On Mon, Nov 2, 2020 at 1:49 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> At Sat, 31 Oct 2020 11:40:53 -0300, Ranier Vilela <ranier.vf@gmail.com> wrote in
> > Per Coverity.
> >
> > If test set->latch against NULL, is why it can be NULL.
> > ResetEvent can dereference NULL.
>
> If the returned event is WL_LATCH_SET, set->latch cannot be NULL. We
> shouldn't inadvertently ignore the unexpected or broken situation.We
> could put Assert instead, but I think that we don't need do something
> here at all since SIGSEGV would be raised at the right location.

Hmm.  I changed that to support set->latch == NULL, so that you can
use the long lived WES in the rare code paths that call WaitLatch()
without a latch (for example the code I proposed at [1]).  The Windows
version leaves the event handle of the most recently used latch in
set->handles[n] (because AFAICS there is no way to have a "hole" in
the handles array).  The event can fire while you are waiting on "no
latch".  Perhaps it should be changed to
ResetEvent(set->handles[cur_event->pos + 1])?

[1]
https://www.postgresql.org/message-id/flat/CA%2BhUKGK1607VmtrDUHQXrsooU%3Dap4g4R2yaoByWOOA3m8xevUQ%40mail.gmail.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Support negative indexes in split_part
Next
From: Nikhil Benesch
Date:
Subject: Re: [PATCH] Support negative indexes in split_part