Infinity bsearch crash on Windows

A 9.1Beta1 test report from Richard Broersma (and confirmed on another
system by Mark Watson) showed up pgsql-testers this week at
http://archives.postgresql.org/pgsql-testers/2011-05/msg00000.php with
the following test crashing his Windows server every time:

SELECT 'INFINITY'::TIMESTAMP;

That works fine for me on Linux. Richard chased the error in the logs,
which was a generic "you can't touch that memory" one, down to a full
stack trace:
http://archives.postgresql.org/pgsql-testers/2011-05/msg00009.php

It looks like it's losing its mind inside of
src/backend/utils/adt/datetime.c , specifically at this line in datebsearch:

3576 while (last >= base)
3577 {
3578 position = base + ((last - base) >> 1);
3579 result = key[0] - position->token[0];

Why crash there only on Windows? Was the problem actually introduced
above this part of the code? These are all questions I have no answer for.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us

On 10 May 2011 23:02, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Why crash there only on Windows?  Was the problem actually introduced above
> this part of the code?  These are all questions I have no answer for.

I don't find it at all surprising that there's a memory corruption bug
that only manifests itself on Windows. Recently, I reported a bug in
pgAdmin that turned out to be a simple case of forgetting to allocate
an extra byte of memory for a null in a c string. The outward problem
couldn't be reproduced on Mac - it only occurred on Linux. Of course,
the problem with undefined behaviour is not that it might cause your
program to crash, but that it might not cause your program to crash.

For debug builds, Visual C++ allocates "no man's land" guard bytes on
either side of areas of allocated memory, which is great for catching
heap corruption bugs. My guess is that when the VC++ debugger issues a
breakpoint, that's exactly where the memory is being
corrupted/improperly dereferenced.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

Greg Smith <greg(at)2ndQuadrant(dot)com> writes:
> A 9.1Beta1 test report from Richard Broersma (and confirmed on another
> system by Mark Watson) showed up pgsql-testers this week at
> http://archives.postgresql.org/pgsql-testers/2011-05/msg00000.php with
> the following test crashing his Windows server every time:

> SELECT 'INFINITY'::TIMESTAMP;

Hmm ... I bet this is related to the recent reports about ALTER USER
VALID UNTIL 'infinity' crashing on Windows. Can the people seeing this
get through the regression tests? Perhaps more to the point, what is
their setting of TimeZone? What does the pg_timezone_abbrevs view show
for them?

regards, tom lane

Tom Lane wrote:
>> SELECT 'INFINITY'::TIMESTAMP;
>>
>
> Hmm ... I bet this is related to the recent reports about ALTER USER
> VALID UNTIL 'infinity' crashing on Windows. Can the people seeing this
> get through the regression tests? Perhaps more to the point, what is
> their setting of TimeZone? What does the pg_timezone_abbrevs view show
> for them?
>

I must have missed that thread, I think I'm missing one of these lists
(pgsql-bugs maybe?). I've cc'd Mark Watson so maybe you can get better
responses without me in the middle if needed; for this one, he reports:

Show timezone gives US/Eastern
Select * from pg_timezone_abbrevs returns zero rows

My Linux system that doesn't have this problem is also in US/Eastern,
too, but I get 189 rows in pg_timezone_abrevs.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD

Greg Smith <greg(at)2ndquadrant(dot)com> writes:
> I must have missed that thread, I think I'm missing one of these lists
> (pgsql-bugs maybe?). I've cc'd Mark Watson so maybe you can get better
> responses without me in the middle if needed; for this one, he reports:

> Show timezone gives US/Eastern
> Select * from pg_timezone_abbrevs returns zero rows

Yeah, the latter confirms my theory about what's going wrong. See
http://archives.postgresql.org/message-id/17311.1305080416@sss.pgh.pa.us
and recent commits.

regards, tom lane