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

From: Sandro Santilli <strk(at)keybit(dot)net>
To: Greg Stark <stark(at)mit(dot)edu>
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 12:11:02
Message-ID: 20140319121102.GJ4042@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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(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.
>
> 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;

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2014-03-19 14:55:51 Re: Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)
Previous Message Sandro Santilli 2014-03-19 11:43:25 Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2014-03-19 12:35:16 Re: Archive recovery won't be completed on some situation.
Previous Message Pavel Stehule 2014-03-19 12:06:51 Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors