Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#5171 closed defect (fixed)

SELECT st_length(st_geomfromtext gives error when running on Proj 6.3 when points input are the same

Reported by: arnghosb Owned by: pramsey
Priority: high Milestone: PostGIS 2.5.8
Component: postgis Version: 3.2.x
Keywords: Cc: arnghosb

Description

SELECT st_length(st_geomfromtext('LINESTRING(-86.848960876 33.448753357,-86.848960876 33.448753357)',4326)::geography); returns ERROR: lwgeom_length_spheroid returned length < 0.0 on ARM (aarch64/Graviton) processor. On Intel processor, it returns the correct output (0.0). Notice that here, the points input are the same, so technically, it should return 0.

Change History (22)

comment:1 by arnghosb, 2 years ago

Summary: SELECT st_length(st_geomfromtext gives error when running on ARM processorSELECT st_length(st_geomfromtext gives error when running on ARM processor when points input are the same

comment:2 by robe, 2 years ago

Can you output what

SELECT postgis_full_version() || ' ' || version();

Testing on my ARM, I get 0 for answer as expected.

I'm running:

POSTGIS="3.3.0dev 0" [EXTENSION] PGSQL="140" GEOS="3.10.2-CAPI-1.16.0" PROJ="8.2.1" GDAL="GDAL 3.4.1, released 2021/12/27" LIBXML="2.9.13" LIBJSON="0.15" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)" TOPOLOGY RASTER PostgreSQL 14.3 (Ubuntu 14.3-1.pgdg22.04+1) on aarch64-unknown-linux-gnu, compiled by gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0, 64-bit

I'll try to install PostGIS 3.2 to see if it's an issue there.

comment:3 by robe, 2 years ago

Okay I was able to replicate the issue on my Amazon RDS instance

That is running:

POSTGIS="3.1.5 0" [EXTENSION] PGSQL="130" GEOS="3.9.1dev-CAPI-1.14.1" PROJ="6.2.1" GDAL="GDAL 2.3.1, released 2018/06/22" LIBXML="2.9.9" LIBJSON="0.12.99" LIBPROTOBUF="1.3.0" WAGYU="0.5.0 (Internal)" TOPOLOGY RASTER PostgreSQL 13.6 on aarch64-unknown-linux-gnu, compiled by aarch64-unknown-linux-gnu-gcc (GCC) 7.4.0, 64-bit

comment:4 by robe, 2 years ago

Milestone: PostGIS 3.2.2PostGIS 3.1.6

comment:5 by arnghosb, 2 years ago

This is the output for the version: POSTGIS="3.2.1 0" [EXTENSION] PGSQL="140" GEOS="3.9.1dev-CAPI-1.14.1" PROJ="6.2.1" LIBXML="2.9.9" LIBJSON="0.12.99" LIBPROTOBUF="1.3.0" WAGYU="0.5.0 (Internal)" PostgreSQL 14.3 on aarch64-u nknown-linux-gnu, compiled by aarch64-unknown-linux-gnu-gcc (GCC) 7.4.0, 64-bit

comment:6 by robe, 2 years ago

Thanks. I'll try 3.2.1 next to see if I can replicate. Might be a GCC bug issue is another thought as I'm running a newer GCC on my ARM.

comment:7 by arnghosb, 2 years ago

Could be an issue with PROJ library. Maybe this is a bug on 6.2.1.

comment:8 by robe, 2 years ago

Ah I think you are right. My earlier test where I was able to replicate the issue was on Amazon Aurora, not RDS.

On RDS the test is fine — my AMZ RDS is running below, a newer proj

POSTGIS="3.1.4 ded6c34" [EXTENSION] PGSQL="140" GEOS="3.9.1-CAPI-1.14.2" PROJ="8.0.1" GDAL="GDAL 3.3.0, released 2021/04/26" LIBXML="2.9.1" LIBJSON="0.15" LIBPROTOBUF="1.3.2" WAGYU="0.5.0 (Internal)" RASTER PostgreSQL 14.1 on aarch64-unknown-linux-gnu, compiled by gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6), 64-bit

comment:9 by robe, 2 years ago

Milestone: PostGIS 3.1.6PostGIS 3.1.7
Summary: SELECT st_length(st_geomfromtext gives error when running on ARM processor when points input are the sameSELECT st_length(st_geomfromtext gives error when running on Proj 6.3 when points input are the same

I think this is a bug with Proj as it's only replicable on proj 6.3.2 and so probably doesn't have anything to do with ARM. arnghosb suggested maybe we go thru the same path as we do for lower geometry. Anyway pushing this off.

comment:10 by pramsey, 2 years ago

Something in geod_inverse that changed?

comment:11 by pramsey, 2 years ago

No great clues in blame. Only two commits in the geod_inverse function, a couple months ago (way more recent than proj 6.2.1):

https://github.com/OSGeo/PROJ/commit/39bb04beba6357a0374fcdb31ee406293a722bf4

And in 2016 (way earlier than 6.2.1)

https://github.com/OSGeo/PROJ/commit/16df65976714747f2ab5fb73a47327970ccd723f#

comment:12 by robe, 2 years ago

But it's 6.3.2 we are talking about. Could the issue have been introduced later.

comment:13 by pramsey, 2 years ago

How much do we truly care? Are we going to submit an upstream patch for a 5-years-out-of-date proj?

comment:14 by robe, 2 years ago

No no need to report to PROJ. I think the question was can we do similar to what we are doing with the non-geoid path that for linestrings where points are the same just return 0, do we need to error at all?

comment:15 by robe, 2 years ago

For clarification, what Arnab was pointing out to me, didn't realize it wasn't on this ticket.

Was that he saw this line:

https://github.com/postgis/postgis/blob/3.2.1/liblwgeom/lwspheroid.c#L202-L205

But it is only done for the non-geographic lib loop. Why can't it be done for the other loop as well.

comment:16 by Paul Ramsey <pramsey@…>, 2 years ago

In 995e505/git:

Short circuit geodesic distance when input points are equal (References #5171)

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

In f1c0c86/git:

Short circuit geodesic distance when input points are equal (References #5171)

comment:18 by Paul Ramsey <pramsey@…>, 2 years ago

In c10f3bb/git:

Short circuit geodesic distance when input points are equal (References #5171)

comment:19 by Paul Ramsey <pramsey@…>, 2 years ago

In f256546/git:

Short circuit geodesic distance when input points are equal (References #5171)

comment:20 by Paul Ramsey <pramsey@…>, 2 years ago

In 612c3aa/git:

Short circuit geodesic distance when input points are equal (References #5171)

comment:21 by robe, 2 years ago

Milestone: PostGIS 3.1.7PostGIS 2.5.9
Resolution: fixed
Status: newclosed

I assume this is done, as branches 2.5-3.3 have the commit

comment:22 by robe, 2 years ago

Milestone: PostGIS 2.5.9PostGIS 2.5.8
Note: See TracTickets for help on using tickets.