Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Ranier Vilela <ranier.vf@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-11-02T03:22:09Z
Lists: 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
Commits
-
Fix WaitLatch(NULL) on Windows.
- a7e65dc88b6f 14.0 landed