Backend crash with TopoGeo_addLinestring against an invalid topology (2)

[strk]

In some circumstance, the TopoGeo_addLinestring function ends up finding N edges forming a ring from one of the edges resulting from the input linestring (this operation is performed by following edge linking information) and later fails to find all the corresponding edge_data records in the topology primitive table.

NOTICE:  failed after trying with tolerance 6.75 : XX000 message: Unexpected error: 6461 edges found when expecting 6462 detail :  hint   :  context: SQ
L statement "SELECT ARRAY(SELECT topology.TopoGeo_addLinestring('test_topo_t4','0102000020E9640000040000003B28C645D88B1A41366677CC3F675B413B28C645B08B1A
4123A36AD93E675B413B28C645608B1A41FD1C51F33C675B413B28C645388B1A41EA5944003C675B41',6.75))"

When such occurrence happens, the cleanup code in _lwt_MakeRingShell attempts to release the expected number of edges, rather than the obtained number of edges, resulting in potential access to unallocated memory (segfault)

This is a followup of #4706 and the fix needs be backported to all relevant branches.

[strk]

Downstream ticket: ​https://github.com/larsop/resolve-overlap-and-gap/issues/1#issuecomment-650104194

[strk]

The fix seems easy, but we need to find out how it is possible to think more edges than available when that's not the case. Theoretically we have a referencial integrity in place so it should NOT be possible for an edge to reference non-existing edges, but maybe such constraint is verified only at the end of the transaction thus leaving the door open to such occurrence. For a test we might intentionally lift the referencial integrity constraint, corrupt the topolody, call the function.

[Sandro Santilli <strk@…>]

In 96615d90/git:

Fix release of unexpected number of edges from a returned edge ring

References #4709 in master branch

[strk]

NOTE: edge linking corruptions are NOT correctly handled by ValidateTopology, as reported in #3042

[strk]

Referencial integrity checks for edge linking are DEFERRED by default, which explains why it is possible to obtain such behavior:

    "next_left_edge_exists" FOREIGN KEY (abs_next_left_edge) REFERENCES city_data.edge_data(edge_id) DEFERRABLE INITIALLY DEFERRED
    "next_right_edge_exists" FOREIGN KEY (abs_next_right_edge) REFERENCES city_data.edge_data(edge_id) DEFERRABLE INITIALLY DEFERRED

[strk]

For the record, while trying a few things to corrupt the topology and invoke the ST_AddEdgeModFace function I'm getting other kind of errors (but no segfaults) like:

 ERROR:  ptarray_contains_point called on unclosed ring

I'll keep trying but those errors should probably also be somehow handled and transformed in a clear message for the user that the underlying topology is corrupted

[Sandro Santilli <strk@…>]

In 2ce98e2/git:

Handle non-closed edge rings by human readable error

Handle both topological and geometrical corruption

Have getRingEdges raise an error if topology is corrupted

References #4709
References #3042

[Sandro Santilli <strk@…>]

In f9db63e/git:

Add test for handling of edge-linking topology corruption

References #4709

[Sandro Santilli <strk@…>]

In 037eba5/git:

Fix release of unexpected number of edges from a returned edge ring

References #4709 in 3.0 branch

[Sandro Santilli <strk@…>]

In 273b7ea/git:

Handle non-closed edge rings by human readable error

Handle both topological and geometrical corruption
Have getRingEdges raise an error if topology is corrupted

Includes test.

References #4709 in 3.0 branch

[Sandro Santilli <strk@…>]

In 8258c16/git:

Fix release of unexpected number of edges from a returned edge ring

References #4709 in 2.5 branch

[Sandro Santilli <strk@…>]

In 456ee52/git:

Handle non-closed edge rings by human readable error

Handle both topological and geometrical corruption
Have getRingEdges raise an error if topology is corrupted

Includes test.

References #4709 in 2.5 branch

[Sandro Santilli <strk@…>]

In 40c8a06d/git:

Fix release of unexpected number of edges from a returned edge ring

Closes #4709 in 2.4 branch

[Sandro Santilli <strk@…>]

In 03e7131/git:

Handle non-closed edge rings by human readable error

Handle both topological and geometrical corruption
Have getRingEdges raise an error if topology is corrupted

Includes test.

References #4709 in 2.4 branch