Opened 13 years ago

Closed 13 years ago

#473 closed defect (fixed)

RightmostEdgeFinder assertion killing postgres process

Reported by: robe Owned by: strk
Priority: major Milestone: 3.3.2
Component: Default Version: 3.3.0
Severity: Unassigned Keywords:
Cc: hogeman@…


I'm running 3.3.1 dev r3463 on windows (PostGIS 1.5.3)

and I have an intensive process that is crashing my postgres process. I think this might have been an issue in 3.3.0 release too because I was hoping to halt my crashing by swapping the GEOS.

The error log reads this before it kicks the bucket and then it kills all postgres processes and doesn't even automatically restart:

Assertion failed: checked>0, file RightmostEdgeFinder.cpp, line 77

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Attachments (1) (5.5 KB ) - added by hogeman 13 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 by robe, 13 years ago

Summary: RightmostEdgeFiner assertion killing postgres processRightmostEdgeFinder assertion killing postgres process

comment:2 by strk, 13 years ago

Any way to isolate the offending operation and operands would be crucial

comment:3 by strk, 13 years ago

Robe: any attempt at figuring out the offending input ?

comment:4 by robe, 13 years ago

Resolution: worksforme
Status: newclosed

I can't replicate this and can't remember what feature set I was using to cause this error. I guess we can close out for now and I'll reopen if I can replicate it.

by hogeman, 13 years ago

Attachment: added

comment:5 by hogeman, 13 years ago

Cc: hogeman@… added

I found a data for reproducing the problem. load attached shapefile like this.

$ shp2pgsql -s 2450 testline testline | psql -d [database] then, this query could reproduce the problem.

# select st_buffer(the_geom, 5.0, 'endcap=square join=mitre mitre_limit=1') from testline;

postgis/postgresql version is...

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


PostgreSQL 9.0.5 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51), 64-bit postgresql log was...

SELECT: RightmostEdgeFinder.cpp:77: void geos::operation::buffer::RightmostEdgeFinder::findEdge(std::vector<geos::geomgraph::DirectedEdge*, std::allocator<geos::geomgraph::DirectedEdge*> >*): Assertion `checked>0' failed. LOG: server process (PID 7464) was terminated by signal 6: Aborted

-- IIDA Tetsushi.

comment:6 by robe, 13 years ago

Resolution: worksforme
Status: closedreopened

now that we have something reproducible strk -- I guess we can reopen eh :)

comment:7 by strk, 13 years ago

Owner: changed from geos-devel@… to strk
Status: reopenednew

I'm on this. The assertion would fail when a caller passes an empty set to RightmostEdgeFinder::findEdge

comment:8 by strk, 13 years ago

Oops, when there is _no_ forward edge, that is

comment:9 by strk, 13 years ago

I've handled to reduce the input this much:

 (-22720.6801580484 130376.223341197,-22620.6136206117 130339.222540348,
  -22620.6133224902 130339.333510463) , 
 (-22720.3807106115 130487.193473695,-22620.3154956134 130450.192663993,
  -22620.315197485 130450.303634126), 
 (-22620.6133224902 130339.333510463,-22620.6127262471 130339.555450692), 
 (-22620.1376011539 130450.303157004,-22620.315197485 130450.303634126), 
 (-22620.315197485 130450.303634126,-22620.3146012281 130450.525574392), 
 (-21480.3713729115 130150.471377565,-21481.6134583498 130150.918429232, 
  -21482.5899891895 130151.031891269,-21480.9946803241 130149.807142948), 
 (-21477.6185334698 130150.46435572,-21478.0611246018 130151.020338484, 
  -21377.8977465929 130114.034129489) 

Trying to reduce further

comment:10 by strk, 13 years ago

The assertion happens after failing to obtain a valid result multiple times as number of precision digits decrease. From 12 to 4, when this occurs:

Creating subgraph from POINT(-21481 130156)
  EdgeEndStart has degree 1
   Adding de EdgeEnd: -21481 130156 - -21480.6666666666679 130156 (backward)

The exception with original precision is:

TopologyException: assigned depths do not match at -22625.3 130450

comment:11 by strk, 13 years ago

JTS succeeds this with the first fixed precision attempt. Fails with the same exception with the original precision:

EX: com.vividsolutions.jts.geom.TopologyException: assigned depths do not match [ (-22625.315179557714, 130450.3170234661, NaN) ]
bufferReducedPrecision: trying with precDigits 12
GOT: MULTIPOLYGON (((-21488.602063 130149.510908,

comment:12 by strk, 13 years ago

Directly using a fixedPrecision of 1e6 (like the one succeeding with JTS) works fine, while arriving there trough a set of reduction doesn't. I suspect there's some status being saved which _should_not_ be.

Inspecting that now that I could finally setup a mirror testcase for JTS

comment:13 by strk, 13 years ago

Oh, silly me. By defining the original precisionModel to 1e6 I'm basically telling WKTWriter to round up, which changes the input !

comment:14 by strk, 13 years ago

Status: newassigned

Alright, it turns out the culprit here is the precision reduction code not fully signaling the precision reduction to all layers of operations. In particular the noder is failing to use the reduced precision thus always failing around the same spot. This in turn triggers further precision reduction until the assertion fails.

I'll have to see the effects of fixing this bug (not exposed in 3.2 because we were using a different noder from the one used by JTS) on the existing testcases. A few testcases would probaby need to be double-checked and updated (pointwise equality checked for buffer output and expecting slightly different results due to different precision level required for a success)

comment:15 by strk, 13 years ago

Resolution: fixed
Status: assignedclosed

Fixed with r3523 in trunk and r3524 in 3.3 branch

Note: See TracTickets for help on using tickets.