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

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: [PATCH][BUG_FIX] Potential null pointer dereferencing.
Дата
Msg-id 20191113.104335.1975009222845696755.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на RE: [PATCH][BUG_FIX] Potential null pointer dereferencing.  (Ranier Vilela <ranier_gyn@hotmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Why overhead of SPI is so large?
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [PATCH] Do not use StdRdOptions in Access Methods