Re: Failure with make check-world for pgtypeslib/dt_test2 with HEAD on OSX
От | Tom Lane |
---|---|
Тема | Re: Failure with make check-world for pgtypeslib/dt_test2 with HEAD on OSX |
Дата | |
Msg-id | 29432.1412643474@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Failure with make check-world for pgtypeslib/dt_test2 with HEAD on OSX (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Failure with make check-world for pgtypeslib/dt_test2
with HEAD on OSX
Re: Failure with make check-world for pgtypeslib/dt_test2 with HEAD on OSX |
Список | pgsql-hackers |
Michael Paquier <michael.paquier@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
В списке pgsql-hackers по дате отправления: