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 16:34:10 |
Message-ID: | 22575.1489077250@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> 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?
After some googling, the answer seems to be that glibc's detection of
double free() is really unreliable for small chunks. It will basically
only notice an extra free of the same chunk most recently freed within a
given bin (size range). Since in the problem at hand there are probably
unrelated free's happening between the two free's mentioning the same
chunk, it's quite easy for it to miss the error. I'm still a bit unsure
why I see the crash in 9.6 but not HEAD, because there's very little
difference between them, but I no longer feel that we need to investigate
more closely.
This all suggests that it might be worth testing ecpg with a debugging
malloc library that has more robust error detection ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Meskes | 2017-03-09 17:45:05 | Re: BUG #14582: ecpg crashes on SQL input |
Previous Message | Tom Lane | 2017-03-09 15:48:56 | Re: BUG #14582: ecpg crashes on SQL input |