Skip site navigation (1) Skip section navigation (2)

pgsql: Prevent datebsearch() from crashing on base == NULL && nel ==0.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Prevent datebsearch() from crashing on base == NULL && nel ==0.
Date: 2011-05-11 00:37:37
Message-ID: E1QJxQn-0001xW-77@gemulon.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-committers
Prevent datebsearch() from crashing on base == NULL && nel == 0.

Normally nel == 0 works okay because the initial value of "last" will be
less than "base"; but if "base" is zero then the calculation wraps around
and we have a very large (unsigned) value for "last", so that the loop can
be entered and we get a SIGSEGV on a bogus pointer.

This is certainly the proximate cause of the recent reports of Windows
builds crashing on 'infinity'::timestamp --- evidently, they're either not
setting an active timezonetktbl, or setting an empty one.  It's not yet
clear to me why it's only happening on Windows and not happening on any
buildfarm member.  But even if that's due to some bug elsewhere, it seems
wise for this function to not choke on the powerup values of
timezonetktbl/sztimezonetktbl.

I also changed the copy of this code in ecpglib, although I am not sure
whether it's exposed to a similar hazard.

Per report and stack trace from Richard Broersma.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/2e82d0b396473b595a30f68b37b8dfd41c37dff8

Modified Files
--------------
src/backend/utils/adt/datetime.c           |   31 +++++++++++++++------------
src/interfaces/ecpg/pgtypeslib/dt_common.c |   31 +++++++++++++++------------
2 files changed, 34 insertions(+), 28 deletions(-)

pgsql-committers by date

Next:From: Bruce MomjianDate: 2011-05-11 00:57:22
Subject: pgsql: Mention "backslash" escape processing change in 9.1 releasenote
Previous:From: Bruce MomjianDate: 2011-05-10 23:44:49
Subject: pgsql: For create/dropdb,only connect once to the server since we now

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group