#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 by , 9 years ago
Version: | → 3.5.0 |
---|
comment:2 by , 9 years ago
Priority: | major → blocker |
---|
comment:4 by , 9 years ago
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 by , 8 years ago
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 by , 8 years ago
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 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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 ?
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.