From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] FIx explicit null dereference pointer (nbtree.c) |
Date: | 2020-04-23 01:28:11 |
Message-ID: | CAEudQAqn7_XtkH3k75KL2e8fOiFe+OAVc57WyZg416f74RR2kQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Em qua., 22 de abr. de 2020 às 21:24, Peter Geoghegan <pg(at)bowt(dot)ie> escreveu:
> On Wed, Apr 22, 2020 at 3:55 PM Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
> > per Coverity.
>
> Some Postgres hackers have access to a dedicated coverity
> installation, and this issue has probably already been dismissed.
>
I will take a note.
>
> > 1. assign_zero: Assigning: opaque = NULL.
> > 2. Condition buf < 0, taking true branch.
> > 3. Condition !(((PageHeader)page)->pd_upper == 0), taking false branch.
> > 4. Condition blkno != orig_blkno, taking true branch.
> > 5. Condition _bt_page_recyclable(page), taking false branch.
> > CID 1314742 (#2 of 2): Explicit null dereferenced (FORWARD_NULL)
> > 6. var_deref_op: Dereferencing null pointer opaque.
>
> This is a false positive. btvacuumpage() is supposed to be a recursive
> function, but in practice the only caller always uses the same block
> number for both blkno and orig_blkno -- the tail recursion is actually
> implemented using goto/a loop.
>
This means that it is impossible for these conditions described by Coverity
to happen on the first call, when the var opaque is NULL.
regards,
Ranier Vilela
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2020-04-23 02:01:03 | Re: Parallel Append can break run-time partition pruning |
Previous Message | Peter Geoghegan | 2020-04-23 01:05:47 | Re: xid wraparound danger due to INDEX_CLEANUP false |