Re: [PATCH][BUG_FIX] Potential null pointer dereferencing.

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: ranier_gyn(at)hotmail(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH][BUG_FIX] Potential null pointer dereferencing.
Date: 2019-11-13 01:43:35
Message-ID: 20191113.104335.1975009222845696755.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 12 Nov 2019 14:03:53 +0000, Ranier Vilela <ranier_gyn(at)hotmail(dot)com> wrote in
> Hi,
> The condition is :
> 74. if (TupIsNull(slot)) is true
> 85. if (TupIsNull(resultTupleSlot)) is true too.

See the definition of TupIsNull. It checks the tupleslot at a valid
pointer is EMPTY as well. And node->ps.ps_ResultTupleSlot cannot be
NULL there since ExecInitUnique initializes it. The sequence is
obvious so even Assert is not needed there, I think.

> If resultTupleSlot is not can be NULL, why test if (TupIsNull(resultTupleSlot))?

It checks if there is no stored "previous" tuple, which is used to
detect the next value. If it is EMPTY (not NULL), it is the first
tuple from the outerPlan as described in the comment just above.

> Occurring these two conditions ExecClearTuple is called, but, don't check by NULL arg.
>
> There are at least 2 more possible cases, envolving ExecClearTuple:
> nodeFunctionscan.c and nodeWindowAgg.c

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-11-13 01:52:52 Re: [PATCH] Do not use StdRdOptions in Access Methods
Previous Message Kyotaro Horiguchi 2019-11-13 01:25:47 Re: Why overhead of SPI is so large?