GEOS 3.4 geos_unit fails on GEOSPreparedGeometry Debian 8 gcc 5.2

[robe]

I've been trying to get GEOS 3.4.3dev to build and regress on new debbie box. Turns out it also fails on old debbie as well. I think what might have instigated the failure was when I upgraded GCC to 5.4

gcc --version

gcc (Debian 5.2.1-21) 5.2.1 20151003
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

g++ --version
g++ (Debian 5.2.1-21) 5.2.1 20151003

Here is output I get from: ​http://debbie.postgis.net:8080/job/GEOS_Branch_3.4/ws/branches/3.4/tests/unit/test-suite.log/*view*/ (last job ​http://debbie.postgis.net:8080/job/GEOS_Branch_3.4/9/console )

geos::operation::buffer::BufferBuilder: .
geos::operation::buffer::BufferOp: ...........
geos::operation::buffer::BufferParameters: ..........
geos::operation::distance::DistanceOp: ...................
geos::operation::geounion::CascadedPolygonUnion: .
geos::operation::geounion::UnaryUnionOp: ......
geos::operation::linemerge::LineMerger: ......
geos::operation::linemerge::LineSequencer: ............
geos::operation::overlay::snap::GeometrySnapper: ..
geos::operation::overlay::snap::LineStringSnapper: .......
geos::operation::overlay::validate::FuzzyPointLocator: .......
geos::operation::overlay::validate::OffsetPointGenerator: .....
geos::operation::overlay::validate::OverlayResultValidator: ......
geos::operation::polygonize::Polygonizer: ..
geos::operation::sharedpaths::SharedPathsOp: .....................
geos::operation::valid::IsValidOp: .
geos::operation::valid::ValidClosedRing: .....
geos::operation::valid::ValidSelfTouchingRingFormingHole: .......
geos::precision::GeometryPrecisionReducer: .........
geos::precision::SimpleGeometryPrecisionReducer: .......
geos::simplify::DouglasPeuckerSimplifier: ...........
geos::simplify::TopologyPreservingSimplifier: ...............
geos::triangulate::Delaunay: .........
geos::triangulate::quadedge::QuadEdge: ...
geos::triangulate::quadedge::QuadEdgeSubdivision: .
geos::util::UniqueCoordinateArrayFilter: .

---> group: capi::GEOSPreparedGeometry, test: test<7>
     problem: assertion failed
     failed assertion: "Values are not equal: expected '1' actual '0'"

tests summary: failures:1 ok:840
FAIL geos_unit (exit status: 1)

GEOS 3.5 branch and trunk seem to regress fine.

[strk]

The failing test was backported to 3.4 by Mateusz via r4066 -- I guess the corresponding fix was not backported.

Mat, could you look at this ? I tried backporting r4081 which seemed related but it didn't help.

[strk]

See also #694

[mloskot]

Quick look, if that assertion failing is this

int ret = GEOSPreparedIntersects(prepGeom1_, geom2_);
ensure_equals(ret, 0);

it means in your environment, the point and segment DO intersect, while

• in environments I have tested
• as well as per confirmation received from Martin Davis

they DO NOT intersect:

There are clear comments in the code as well as final conclusions in ticket #591 and ​​https://github.com/libgeos/libgeos/pull/40 with Martin Davis' input.

There is nothing to do about it really, or, disable the test as too fragile? Before that, I would suggest to read through the discussion with Martin first.

[strk]

Could you provide a short summary of why trunk and 3.5 do pass while 3.4 does not ? The referenced discussion is way too long for me.

Bottom line: if it's NOT a regression but a NEW FAILING TEST, then I'm ok with disabling the test (and keep a ticket open to report the still-unfixed bug).

[strk]

So I compared trunk (3.6) and 3.4 branches and the _same_ test expects a ensure_equals(ret, 1) in 3.4 (which fails) and ensure_qeuals(ret, 0) in trunk (which passes).

Of course the code is stable, only the expactance is different, for I don't see which reason.

[strk]

This issue should now be fixed with r4148. Regina, I hadn't seen Debbie building the 3.4 since December, does it need a push ?

[strk]

Ticket retargeted after milestone deleted