Opened 10 years ago
Closed 10 years ago
#2950 closed defect (fixed)
ST_ClipByBox2D crashes backend
Reported by: | strk | Owned by: | strk |
---|---|---|---|
Priority: | blocker | Milestone: | PostGIS 2.2.0 |
Component: | postgis | Version: | master |
Keywords: | Cc: |
Description
I've found inputs that make ST_ClipByBox2D stuck, and attempts to interrupt it eventually crashes the backend.
It's some geometries in the gadm4 dataset. Those with cartodb_id=5 in the gadm4 test created as part of Windshaft-CartoDB tests.
This is probably a GEOS issue, anyway the symptom bubbles up here so I'm marking it as a blocker here (GEOS-3.5.0 isn't out yet)
Change History (5)
comment:1 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 10 years ago
Summary: | Make ST_ClipByBox2D interruptible → ST_ClipByBox2D crashes backend |
---|
comment:3 by , 10 years ago
Simpler case:
CREATE TEMPORARY TABLE t AS SELECT 'POLYGON((41 20,41 0,21 0,1 20,1 40,21 40,41 20))' ::geometry g; SELECT ST_AsText(ST_ClipByBox2d(g, ST_MakeEnvelope(-20,-20,-10,-10))) FROM t;
comment:4 by , 10 years ago
Got it, it's a wrong index passed to PG_FREE_IF_COPY :'( It's scary to realize such error is not catched by PostgreSQL at compile time...
Note:
See TracTickets
for help on using tickets.
It actually seems to be a postgis issue, in that copying the offending input and using it as a literal fixes the problem, so it must have to do with memory management inside postgis.
The working query is:
SELECT ST_ClipByBox2d('0103000020110F00000100000008000000AA2120B4A7FB1241ECF43DA6E035524154CA0AA7A2FB1241E021BA67DD35524103868A5979FB1241A20C161ADC355241B9B52D4A3BFB12411890EA10DD3552416F3B80D811FB12418D1BAAA7DF355241C9C8206726FB1241C867BFE6E235524174D4D4B76EFB12415A4A8635E4355241AA2120B4A7FB1241ECF43DA6E0355241', 'BOX(-2661231.576776697 2348145.508920613,156543.033928043 5165920.119625353)'::box2d);
But if the geometry is retrived from a table, then it doesn't work anymore: