Opened 3 months ago

Closed 6 weeks ago

Last modified 6 weeks 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, 3 months 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, 3 months 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, 3 months 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, 3 months ago

Milestone: PostGIS 3.2.2PostGIS 3.1.6

comment:5 by arnghosb, 3 months 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, 3 months 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, 3 months ago

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

comment:8 by robe, 3 months 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 months 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, 6 weeks ago

Something in geod_inverse that changed?

comment:11 by pramsey, 6 weeks 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, 6 weeks ago

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

comment:13 by pramsey, 6 weeks 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, 6 weeks 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, 6 weeks 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@…>, 6 weeks ago

In 995e505/git:

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

comment:17 by Paul Ramsey <pramsey@…>, 6 weeks ago

In f1c0c86/git:

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

comment:18 by Paul Ramsey <pramsey@…>, 6 weeks ago

In c10f3bb/git:

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

comment:19 by Paul Ramsey <pramsey@…>, 6 weeks ago

In f256546/git:

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

comment:20 by Paul Ramsey <pramsey@…>, 6 weeks ago

In 612c3aa/git:

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

comment:21 by robe, 6 weeks 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, 6 weeks ago

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