Michael Paquier <michael.paqu...@gmail.com> writes:
> Hm... I have tried changing the system locales (to en_US for example) and
> time format but I can still trigger the issue all the time. I'll try to
> have a closer look.. It looks like this test does not like some settings at
> the OS level.
I eventually realized that the critical difference was you'd added
"CFLAGS=" to the configure call. On this platform that has the net
effect of removing -O2 from the compiler flags, and apparently that
shifts around the stack layout enough to expose the clobber.
The fix is simple enough: ecpg's version of ParseDateTime is failing
to check for overrun of the field[] array until *after* it's already
clobbered the stack:
*** a/src/interfaces/ecpg/pgtypeslib/dt_common.c
--- b/src/interfaces/ecpg/pgtypeslib/dt_common.c
*************** ParseDateTime(char *timestr, char *lowst
*** 1695,1703 ****
while (*(*endstr) != '\0')
{
/* Record start of current field */
- field[nf] = lp;
if (nf >= MAXDATEFIELDS)
return -1;
/* leading digit? then date or time */
if (isdigit((unsigned char) *(*endstr)))
--- 1695,1703 ----
while (*(*endstr) != '\0')
{
/* Record start of current field */
if (nf >= MAXDATEFIELDS)
return -1;
+ field[nf] = lp;
/* leading digit? then date or time */
if (isdigit((unsigned char) *(*endstr)))
Kind of astonishing that nobody else has reported this, given that
there's been a regression test specifically meant to catch such a
problem since 4318dae. The stack layout in PGTYPESdate_from_asc
must happen to avoid the issue on practically all platforms.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
