Thread: Re: [BUGS] BUG #6046: select current_date crashes postgres

On 1/06/2011 1:28 AM, Rikard Pavelic wrote:
>
> The following bug has been logged online:
>
> Bug reference:      6046
> Logged by:          Rikard Pavelic
> Email address:      rikard.pavelic@zg.htnet.hr
> PostgreSQL version: 9.1 beta 1
> Operating system:   Windows 7 64bit
> Description:        select current_date crashes postgres
> Details:
>
> select current_time
> or select current_date
>
> results in postgres crash.

OK. I created the 'crashdumps' directory, gave the 'postgres' account 
full control and re-tested. The resulting dump can be debugged in Visual 
Studio Express 2008 (not 2010 - they removed that feature - but you can 
use windbg) - and shows:

>    postgres.exe!datebsearch(const char * key=0x005ef004, const datetkn * base=0xffffffff, int nel=-1)  Line 3579
C
>      postgres.exe!DecodeSpecial(int field=0, char * lowtoken=0x005ef004, int * val=0x005eee78)  Line 2789 + 0x11
bytes   C
 
>      postgres.exe!DecodeTimeOnly(char * * field=0x005eef3c, int * ftype=0x005eefa0, int nf=1, int * dtype=0x005eef0c,
pg_tm* tm=0x005eef10, int * fsec=0x005eef08, int * tzp=0x005eef00)  Line 1921 + 0xf bytes    C
 
>      postgres.exe!timetz_in(FunctionCallInfoData * fcinfo=0x005ef060)  Line 1864 + 0x2b bytes    C
>      postgres.exe!InputFunctionCall(FmgrInfo * flinfo=0x01d122bc, char * str=0x01d14090, unsigned int
typioparam=1266,int typmod=-1)  Line 1909 + 0x3a bytes    C
 
>      postgres.exe!ExecEvalCoerceViaIO(CoerceViaIOState * iostate=0x01d12290, ExprContext * econtext=0x01d12198, char
*isNull=0x01d12470, ExprDoneCond * isDone=0x01d12508)  Line 4064 + 0x10 bytes    C
 
>      postgres.exe!ExecTargetList(List * targetlist=0x01d124f0, ExprContext * econtext=0x01d12198, unsigned int *
values=0x01d12460,char * isnull=0x01d12470, ExprDoneCond * itemIsDone=0x01d12508, ExprDoneCond * isDone=0x005ef310)
Line5107 + 0x27 bytes    C
 
>      postgres.exe!ExecProject(ProjectionInfo * projInfo=0x01d12480, ExprDoneCond * isDone=0x005ef310)  Line 5324 +
0x18bytes    C
 
>      postgres.exe!ExecResult(ResultState * node=0x00000000)  Line 157    C
>      postgres.exe!ExecProcNode(PlanState * node=0x01d12110)  Line 367 + 0x6 bytes    C
>      postgres.exe!ExecutePlan(EState * estate=0x00000000, PlanState * planstate=0x01d12110, CmdType
operation=CMD_SELECT,char sendTuples='
', long numberTuples=0, ScanDirection direction=NoMovementScanDirection,
_DestReceiver* dest=0x01b1f800)  Line 1386 + 0xa bytes    C
 
>      postgres.exe!standard_ExecutorRun(QueryDesc * queryDesc=0x7ffd7000, ScanDirection direction=6223960, long
count=2008331305) Line 318 + 0x15 bytes    C
 
>      kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes    

It looks like the issue is that an invalid pointer is passed for `base'. 
`base' is used to calculate `position' which is then dereferenced - and 
splat!

I suspect - but haven't verified - that the reason `base' is shown as 
0xffffffff rather than NULL is that the optimizer has done away with the 
'position' variable, instead using the 'base' variable passed as a 
parameter. There isn't any 'position' variable in the local stack.

The static global `timezonetktbl' in src\backend\utils\adt\datetime.c is 
NULL. The calling function passes 'timezonetktbl' as the 'base' argument 
of datebsearch(...). So I'd say that 0xffffffff is just an artifact of 
the optimizer's work, and `base' was really passed as NULL.

So - for some reason the time zone tables aren't getting loaded, or 
InstallTimeZoneAbbrevs(...) isn't being called to activate them.

Is anyone aware of any changes between 9.0 and 9.1beta that messed with 
time zone handling and loading?

-- 
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

On 1/06/2011 9:01 AM, Craig Ringer wrote:

> Is anyone aware of any changes between 9.0 and 9.1beta that messed with
> time zone handling and loading?

By the way, it looks like using any of:
  SELECT 'now'::timestamp;  SELECT 'now'::timestamptz;  SELECT current_time;  SELECT current_date;  SELECT localtime;
SELECTlocaltimestamp;  SELECT CAST( now() AS date );
 

will also trigger a crash. However, none of these statements do:
  SELECT current_timestamp;  SELECT now();  SELECT now() :: timestamptz;  SELECT now() :: timestamp;

-- 
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

Craig Ringer <craig@postnewspapers.com.au> writes:
> On 1/06/2011 9:01 AM, Craig Ringer wrote:
>> Is anyone aware of any changes between 9.0 and 9.1beta that messed with
>> time zone handling and loading?

> By the way, it looks like using any of:

>    SELECT 'now'::timestamp;
>    SELECT 'now'::timestamptz;
>    SELECT current_time;
>    SELECT current_date;
>    SELECT localtime;
>    SELECT localtimestamp;
>    SELECT CAST( now() AS date );

> will also trigger a crash.

This is the known problem with timezone abbreviations not being
initialized correctly on Windows --- anything involving interpreting a
"keyword" in datetime input will go belly up.  See commits 2e82d0b39,
e05b86644.
        regards, tom lane