Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1658 closed defect (fixed)

Crash in ST_Project on NULL input

Reported by: realityexists Owned by: pramsey
Priority: critical Milestone: PostGIS 2.0.0
Component: postgis Version: master
Keywords: Cc:


Rev 9402. Running


Causes the backend to crash with an access violation/segmentation fault. Happens on both Linux and Windows.

#0  pg_detoast_datum (datum=0x0) at fmgr.c:2233
#1  0x0051d0d6 in geography_project (fcinfo=0x99b76a4) at geography_measurement.c:615
#2  0x081b6cf8 in ExecMakeFunctionResultNoSets (fcache=0x99b7668, econtext=0x9952060, 
    isNull=0xbf8c033f "", isDone=0x0) at execQual.c:1890

Attachments (1)

project.patch (461 bytes ) - added by pramsey 12 years ago.

Download all attachments as: .zip

Change History (4)

by pramsey, 12 years ago

Attachment: project.patch added


comment:1 by pramsey, 12 years ago

Can you think of any reason this function shouldn't be defined as strict? the only reason would be to allow a null argument to produce a non-null result… I feel like there's a reason this is not strict… like we return a NULL Azimuth in the case of a zero distance?

comment:2 by pramsey, 12 years ago

Resolution: fixed
Status: newclosed

Yes, I remembered. We want to be able to pass in a NULL azimuth, but not necessarily a null anything else. Should be good at r9414.

comment:3 by realityexists, 12 years ago

Thanks, that fixed it. Yes, a NULL azimuth with a zero distance was the reason it's not strict, though it's a bit unexpected that NULL gets treated as 0 for non-zero distances, eg.

SELECT ST_AsText(ST_Project('POINT(10 10)'::geography, 10000, NULL))

Then again, having it return NULL for non-zero distance, but non-NULL for zero distance might seem strange, too. I don't know what the "right" behaviour would be here.

Note: See TracTickets for help on using tickets.