Re: [PATCH][BUG_FIX] Potential null pointer dereferencing. - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: [PATCH][BUG_FIX] Potential null pointer dereferencing.
Date
Msg-id 20191113.104335.1975009222845696755.horikyota.ntt@gmail.com
Whole thread Raw
In response to RE: [PATCH][BUG_FIX] Potential null pointer dereferencing.  (Ranier Vilela <ranier_gyn@hotmail.com>)
List pgsql-hackers
At Tue, 12 Nov 2019 14:03:53 +0000, Ranier Vilela <ranier_gyn@hotmail.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



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Why overhead of SPI is so large?
Next
From: Amit Langote
Date:
Subject: Re: [PATCH] Do not use StdRdOptions in Access Methods