From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | "Dudley, Michael" <mdudley(at)gryphonsensors(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14582: ecpg crashes on SQL input |
Date: | 2017-03-09 15:48:56 |
Message-ID: | 20743.1489074536@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Michael Meskes <meskes(at)postgresql(dot)org> writes:
> Could you try the attached patch please?
Wow, that's certainly a bug fix, and it does stop the crash in 9.6 for me,
but I'm not sure that I follow how come the failure seems to be version-
and data-dependent. It looks like, because of this bug, you ought to
reliably have a double free() occurring any time there's more than one
dollar-quoted constant in ecpg's input. Why doesn't glibc notice?
I think that in most cases, the malloc block used for dolqstart would have
been handed out again for another temporary string by the time we reach
the second dollar-quoted constant, so the second free(dolqstart) in itself
wouldn't look like an error to glibc. But when the temporary string is
freed for real, a bit later, that should result in an error. Does ecpg
leak a large fraction of its temporary strings?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-03-09 16:34:10 | Re: BUG #14582: ecpg crashes on SQL input |
Previous Message | Michael Meskes | 2017-03-09 14:56:47 | Re: BUG #14582: ecpg crashes on SQL input |