Opened 4 years ago

Closed 3 years ago

#4740 closed defect (fixed)

Berrie64 pg13 branch - weird regress failure on tickets

Reported by: robe Owned by: robe
Priority: high Milestone: PostGIS 3.0.4
Component: postgis Version: 2.5.x -- EOL
Keywords: Cc:

Description

I'm going to retest this to make sure it's not a fluke. Odd that it's happening only on berrie64 which rarely has problems.

17:34:03 Checking for shp2pgsql ... found
17:34:03 Checking for pgsql2shp ... found
17:34:03 TMPDIR is /tmp/pgis_reg
17:34:03 Creating database 'postgis_reg' 
17:34:06 Preparing db 'postgis_reg' using: CREATE EXTENSION postgis SCHEMA public
17:34:11 PostgreSQL 13beta2 on aarch64-unknown-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
17:34:11   Postgis 3.1.0dev - (e6c9403) - 2020-08-13 21:20:36
17:34:11   scripts 3.1.0dev e6c9403
17:34:11   GEOS: 3.7.1-CAPI-1.11.1 27a5e771
17:34:11   PROJ: Rel. 5.2.0, September 15th, 2018

17:35:44 -----------------------------------------------------------------------------
17:35:44 --- tickets_expected	2020-08-13 14:19:28.517337391 -0700
17:35:44 +++ /tmp/pgis_reg/test_103_out	2020-08-13 14:35:44.156985845 -0700
17:35:44 @@ -433,4 +433,4 @@
17:35:44  #4670-3|LINESTRING(0 0,1 1,3 3,2 2,4 4)
17:35:44  #4670-4|LINESTRING(0 0,1 1,3 3,4 4,2 2)
17:35:44  ERROR:  LWGEOM_addpoint: Invalid offset
17:35:44 -#4689|0
17:35:44 +#4689|5.92515031139973e-11
17:35:44 -----------------------------------------------------------------------------

Change History (17)

comment:1 by robe, 4 years ago

oh wait it's been failing for more than this run so not a fluke

comment:2 by robe, 4 years ago

the test that is failing is this which is to test #4689

SELECT '#4689', _ST_DistanceTree('POLYGON ((30 10, 40 40, 20 40, 30 10))'::geography, 'POLYGON((81 6,140 35,-70 18,-51 0,-60 -46,106 -6,81 6))

comment:3 by robe, 4 years ago

Maybe this was left over from something — the 3.0 that I triggered seemed to have passed. I'll trigger 2.5 run and see if it still shows error.

comment:4 by robe, 4 years ago

Resolution: worksforme
Status: newclosed

okay guess this was a fluke maybe it had something to do with a loose liblwgeom somewhere that got cleared. 2.5 seems to have passed the hump already.

comment:5 by robe, 4 years ago

Resolution: worksforme
Status: closedreopened

okay it happened againbut in 3.1.0 run. Hmm an according to debbie it's been failing every single time except on 8/14 run for 3.0.2dev. Very baffling.

Okay

03:37:19 PostgreSQL 13beta2 on aarch64-unknown-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
03:37:19   Postgis 3.1.0dev - (866293b) - 2020-08-15 07:25:55
03:37:19   scripts 3.1.0dev 866293b
03:37:19   GEOS: 3.7.1-CAPI-1.11.1 27a5e771
03:37:19   PROJ: Rel. 5.2.0, September 15th, 2018
03:37:19 

03:38:25 --- tickets_expected	2020-08-15 00:24:42.348748491 -0700
03:38:25 +++ /tmp/pgis_reg/test_103_out	2020-08-15 00:38:25.380045943 -0700
03:38:25 @@ -433,4 +433,4 @@
03:38:25  #4670-3|LINESTRING(0 0,1 1,3 3,2 2,4 4)
03:38:25  #4670-4|LINESTRING(0 0,1 1,3 3,4 4,2 2)
03:38:25  ERROR:  LWGEOM_addpoint: Invalid offset
03:38:25 -#4689|0
03:38:25 +#4689|5.92515031139973e-11
Last edited 4 years ago by robe (previous) (diff)

comment:6 by Algunenano, 4 years ago

Priority: mediumhigh

I'm also seeing this in my local dev machine after updating to HEAD:

--- tickets_expected    2020-08-17 16:08:40.810017012 +0200
+++ /tmp/pgis_reg/test_103_out  2020-08-17 16:29:56.118769957 +0200
@@ -433,4 +433,4 @@
 #4670-3|LINESTRING(0 0,1 1,3 3,2 2,4 4)
 #4670-4|LINESTRING(0 0,1 1,3 3,4 4,2 2)
 ERROR:  LWGEOM_addpoint: Invalid offset
-#4689|0
+#4689|5.9583730430112e-11

comment:7 by robe, 4 years ago

@Algunenano does it happen on your machine consistently? I've only seen it on the Rasberry Pi 64 and I think it doesn't always happen.

I thought originally it was pramsey's change in #4689 but I'm guessing it might not be the code change and it's just the addition of the test he aded that is exposing an issue that has always been there.

comment:8 by Algunenano, 4 years ago

@Algunenano does it happen on your machine consistently? I've only seen it on the Rasberry Pi 64 and I think it doesn't always happen.

Yes, it happens everytime I run the regress tests. I'm building with clang, both with -O2 and with -march=native -mtune=native -O3. Using GEOS HEAD.

comment:9 by Algunenano, 4 years ago

It seems this looks similar to #2168.

In geography_distance there is a round to nanometers to avoid this:

	/* Knock off any funny business at the nanometer level, ticket #2168 */
	distance = round(distance * INVMINDIST) / INVMINDIST;

Which is not present in geography_distance_tree. @pramsey do you think it's the same issue and should be solved in the same way or it should be investigated further?

comment:10 by Algunenano, 4 years ago

This is still broken (so it's a pita any time I try to do anything in Postgis, which hasn't been much recently). @pramsey any thoughts?

in reply to:  9 comment:11 by pramsey, 4 years ago

Replying to Algunenano:

@pramsey do you think it's the same issue and should be solved in the same way or it should be investigated further?

Round it off.

comment:12 by Regina Obe <lr@…>, 4 years ago

In 3bcbbee/git:

References #4740 Round off geography_distance_tree

comment:13 by robe, 4 years ago

Resolution: fixed
Status: reopenedclosed

closing this out since berrie64 seems to have passed this hump.

comment:14 by Algunenano, 4 years ago

Thanks @robe, it also fixed it for me.

comment:15 by robe, 4 years ago

Milestone: PostGIS 3.1.0PostGIS 3.0.4
Resolution: fixed
Status: closedreopened

Berrie64 is having the same failure on 3.0.4dev, so reopening until we backport it to 3.0 branch.

comment:16 by robe, 4 years ago

Owner: changed from pramsey to robe
Status: reopenednew

comment:17 by Paul Ramsey <pramsey@…>, 3 years ago

Resolution: fixed
Status: newclosed

In c07bff3/git:

Match tree to brute force return in geography distance, closes #4740

Note: See TracTickets for help on using tickets.