Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)
Дата
Msg-id CAM-w4HNWVuNqo0d8DUNg5Ucaw6wnx7yzWv6zKnK5RRFN=_rT4Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)  (Sandro Santilli <strk@keybit.net>)
Ответы Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)  (Sandro Santilli <strk@keybit.net>)
Re: Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Дерево обсуждения 
On Wed, Mar 19, 2014 at 8:57 AM, Sandro Santilli <strk@keybit.net> wrote:
> ==21240==    by 0x64A200: newdfa.isra.4 (rege_dfa.c:307)
> ==21240==    by 0x64A4C3: getsubdfa (regexec.c:285)
> ==21240==    by 0x64B80A: cdissect (regexec.c:673)
> ==21240==    by 0x64C802: pg_regexec (regexec.c:473)


It looks like a simple bug pg_regexec where it's reusing a loop
counter "n" to mean two different things. When it goes to free all the
subdfas it looks like the code was written based "n" still being the
number of trees but in fact it's been reused to be the number of
matches.


--
greg

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

Предыдущее
От: Sandro Santilli
Дата:
Сообщение: Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)
Следующее
От: Dave Page
Дата:
Сообщение: Re: BUG #9619: error creating plperl , plperlu language , plperl.dll error