Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)
В списке pgsql-bugs по дате отправления:
| От | Sandro Santilli |
|---|---|
| Тема | Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?) |
| Дата | |
| Msg-id | 20140319121102.GJ4042@localhost обсуждение исходный текст |
| Ответ на | Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?) (Sandro Santilli <strk@keybit.net>) |
| Список | pgsql-bugs |
On Wed, Mar 19, 2014 at 12:43:25PM +0100, Sandro Santilli wrote: > On Wed, Mar 19, 2014 at 10:57:10AM +0000, Greg Stark wrote: > > 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. > > I confirm this patch fixes the leak: I've encoded another version of it as a pull request: https://github.com/postgres/postgres/pull/5 --strk;
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера