Opened 12 years ago

Closed 12 years ago

#1351 closed defect (fixed)

ST_Buffer around A LINESTRING crashes the database

Reported by: royl Owned by: pramsey
Priority: critical Milestone: PostGIS 2.0.0
Component: postgis Version: 1.5.X
Keywords: Cc:

Description

The attached query attempts to create a buffer around a LINESTRING. This LINESTRING is the result of a real trajectory of a user inside the city of Beijing (sorry for the huge size). Executing this query crashes the database.

Attachments (1)

bad_raw_trajectory.sql (468.2 KB ) - added by royl 12 years ago.
run this sql script and see the problem

Download all attachments as: .zip

Change History (9)

by royl, 12 years ago

Attachment: bad_raw_trajectory.sql added

run this sql script and see the problem

comment:1 by strk, 12 years ago

Please report the output of:

 SELECT postgis_full_version();

comment:2 by royl, 12 years ago

postgis_full_version


POSTGIS="1.5.3" GEOS="3.2.2-CAPI-1.6.2" PROJ="Rel. 4.7.1, 23 September 2009" LIBXML="2.7.8" USE_STATS

(1 row)

comment:3 by strk, 12 years ago

royl: try updating GEOS to 3.3.1

comment:4 by royl, 12 years ago

I now upgraded geos. Here is my version now:

postgis=# select postgis_full_version();

postgis_full_version


POSTGIS="1.5.3" GEOS="3.3.1-CAPI-1.7.1" PROJ="Rel. 4.7.1, 23 September 2009" LIBXML="2.7.8" USE_STATS

(1 row)

However, the problem still persists. Here is the error message I get after running the query for a very long time (a few hours):

The connection to the server was lost. Attempting reset: Failed. !>

comment:5 by strk, 12 years ago

Confirmed. The buffer computation uses a lot of memory which may result in an OOM condition causing the crash.

As a workaround you may try to compute the buffer incrementally where each step should reduce the number of segments opefully making it easier on memory.

Something like:

select st_buffer(st_buffer(st_buffer(st_buffer(st_buffer(the_geom, 1), 2), 7), 10), 30) from bad_raw_trajectory;

In any case this is a GEOS issue.

comment:6 by strk, 12 years ago

Actually, the incremental buffer approach crashed nonetheless, with the known assertion failure:

RightmostEdgeFinder.cpp:76: void geos::operation::buffer::RightmostEdgeFinder::findEdge(std::vector<geos::geomgraph::DirectedEdge*, std::allocator<geos::geomgraph::DirectedEdge*> >*): Assertion `checked>0' failed.

That one should be fixed already in GEOS development version. See: http://trac.osgeo.org/geos/ticket/473

comment:7 by strk, 12 years ago

I confirm it's fixed with GEOS SVN:

2011-12-07 14:05:30 CET LOG:  duration: 197622.410 ms  statement: select st_summary(st_buffer(st_buffer(st_buffer(st_buffer(st_buffer(the_geom, 1), 2), 7), 10), 30)) from bad_raw_trajectory;

         st_summary         
----------------------------
 Polygon[B] with 24 rings
    ring 0 has 64521 points
    ring 1 has 8 points
    ring 2 has 1922 points
    ring 3 has 1206 points
    ring 4 has 3868 points
    ring 5 has 840 points
    ring 6 has 293 points
    ring 7 has 11 points
    ring 8 has 1238 points
    ring 9 has 10396 points
    ring 10 has 315 points
    ring 11 has 53 points
    ring 12 has 1028 points
    ring 13 has 6463 points
    ring 14 has 36 points
    ring 15 has 249 points
    ring 16 has 273 points
    ring 17 has 58 points
    ring 18 has 48 points
    ring 19 has 126 points
    ring 20 has 170 points
    ring 21 has 3408 points
    ring 22 has 8 points
    ring 23 has 9297 points

comment:8 by strk, 12 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.