| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Sandro Santilli <strk(at)keybit(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?) |
| Date: | 2014-03-19 10:57:10 |
| Message-ID: | CAM-w4HNWVuNqo0d8DUNg5Ucaw6wnx7yzWv6zKnK5RRFN=_rT4Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
On Wed, Mar 19, 2014 at 8:57 AM, Sandro Santilli <strk(at)keybit(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Page | 2014-03-19 11:08:02 | Re: BUG #9619: error creating plperl , plperlu language , plperl.dll error |
| Previous Message | Sandro Santilli | 2014-03-19 08:57:02 | Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?) |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2014-03-19 11:35:42 | Re: B-tree descend for insertion locking |
| Previous Message | Heikki Linnakangas | 2014-03-19 10:57:02 | Re: Archive recovery won't be completed on some situation. |