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

From Sandro Santilli
Subject Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)
Date
Msg-id 20140319121102.GJ4042@localhost
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>)
List 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 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: Markus Nussdorfer
Date:
Subject: Re: BUG #8660: RPM installation of 9.2.6 have dependency problem