Re: BUG #16837: Invalid memory access on \h in psql

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #16837: Invalid memory access on \h in psql
Дата
Msg-id 2176557.1611677482@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #16837: Invalid memory access on \h in psql  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: BUG #16837: Invalid memory access on \h in psql  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-bugs
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> At Tue, 26 Jan 2021 07:00:00 +0000, PG Bug reporting form <noreply@postgresql.org> wrote in
>> When executing in psql (under valgrind):
>> \h\
>> valgrind detects the following error:
>> ==00:00:00:00.000 3226182==
>> ==00:00:00:04.045 3226182== Conditional jump or move depends on
>> uninitialised value(s)

> This is reproducible on master HEAD. helpSQL assumes that the first
> word is longer than two characters and the second word exists. It also
> doesn't care overruns. Addition to those issues, it miscounts the
> length of the first two words if the third word exists.

Weirdly, valgrind isn't whining about this for me.  But I agree that
that loop is unsafe.  There are other problems too I think: neither
the initialization of "output" nor the calculation of nl_count seem
to be done sanely.  This function really needs thoroughgoing review :-(

            regards, tom lane



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tobias Gierke
Дата:
Сообщение: Re: Assignment to composite type variable fails inside function but running query separately yields correct type & value ?
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: BUG #16794: BEFORE UPDATE FOR EACH ROW triggers on partitioned tables can break tuple moving UPDATEs