Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#751 closed defect (fixed)

GEOS 3.4 geos_unit fails on GEOSPreparedGeometry Debian 8 gcc 5.2

Reported by: robe Owned by: mloskot
Priority: blocker Milestone: 3.6.1
Component: Unit Tests Version: 3.5.0
Severity: Unassigned Keywords:
Cc:

Description

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.

Change History (8)

comment:1 Changed 3 years ago by strk

Version: 3.5.0

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.

comment:2 Changed 3 years ago by strk

Priority: majorblocker

comment:3 Changed 3 years ago by strk

See also #694

comment:4 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by 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).

comment:6 Changed 3 years ago by 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.

comment:7 Changed 3 years ago by strk

Resolution: fixed
Status: newclosed

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 ?

comment:8 Changed 2 years ago by strk

Milestone: 3.4.33.6.1

Ticket retargeted after milestone deleted

Note: See TracTickets for help on using tickets.