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 20140319114325.GG4042@localhost
Whole thread Raw
In response to Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)  (Greg Stark <stark@mit.edu>)
Responses Re: Leaking regexp_replace in 9.3.1 ? (was: [HACKERSUninterruptable regexp_replace in 9.3.1 ?)
List pgsql-bugs
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:

diff --git a/src/backend/regex/regexec.c b/src/backend/regex/regexec.c
index 0edb83c..2e97662 100644
--- a/src/backend/regex/regexec.c
+++ b/src/backend/regex/regexec.c
@@ -259,6 +259,7 @@ pg_regexec(regex_t *re,
        /* clean up */
        if (v->pmatch != pmatch && v->pmatch != mat)
                FREE(v->pmatch);
+       n = (size_t) v->g->ntree;
        for (i = 0; i < n; i++)
        {
                if (v->subdfas[i] != NULL)

--strk;

pgsql-bugs by date:

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