Postgres Pro
Downloads
Home   >   mailing lists

Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?) - Mailing list pgsql-bugs

From Greg Stark
Subject Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)
Date
Msg-id CAM-w4HNWVuNqo0d8DUNg5Ucaw6wnx7yzWv6zKnK5RRFN=_rT4Q@mail.gmail.com
Whole thread Raw
In response to Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)  (Sandro Santilli <strk@keybit.net>)
Responses 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>)
List pgsql-bugs
Tree view 
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 by date:

Previous
From: Sandro Santilli
Date:
Subject: Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)
Next
From: Dave Page
Date:
Subject: Re: BUG #9619: error creating plperl , plperlu language , plperl.dll error