Re: Failure with make check-world for pgtypeslib/dt_test2 with HEAD on OSX - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Failure with make check-world for pgtypeslib/dt_test2 with HEAD on OSX
Date
Msg-id CAB7nPqQ-fgu+p-Z5N=juuSjuHhTckhQCgjbE_Exw3+MzJjBM9A@mail.gmail.com
Whole thread Raw
In response to Re: Failure with make check-world for pgtypeslib/dt_test2 with HEAD on OSX  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Oct 7, 2014 at 9:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.

At least my scripts are weird enough to trigger such behaviors. The funny part is that it's really a coincidence, CFLAGS was being set with an empty variable, variable removed in this script some time ago.

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:
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.
Yes, thanks. That's it. At least I am not going crazy.
Regards,
--
Michael

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Failure with make check-world for pgtypeslib/dt_test2 with HEAD on OSX
Next
From: Ali Akbar
Date:
Subject: Re: Last Commitfest patches waiting review