RightmostEdgeFinder assertion killing postgres process

[robe]

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.

[strk]

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

[strk]

Robe: any attempt at figuring out the offending input ?

[robe]

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.

[hogeman]

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"

LIBXML="2.6.26" USE_STATS

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.

[robe]

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

[strk]

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

[strk]

Oops, when there is _no_ forward edge, that is

[strk]

I've handled to reduce the input this much:

MULTILINESTRING( 
 (-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

[strk]

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

[strk]

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,

[strk]

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

[strk]

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

[strk]

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)

[strk]

Fixed with r3523 in trunk and r3524 in 3.3 branch