st_3dintersection causing core dump

[cege]

PostgreSQL 13.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1), 64-bit

"POSTGIS="3.1.4 ded6c34" [EXTENSION] PGSQL="130" GEOS="3.9.1-CAPI-1.14.2" SFCGAL="1.3.7" PROJ="8.1.0" LIBXML="2.9.7" LIBJSON="0.13.1" LIBPROTOBUF="1.3.0" WAGYU="0.5.0 (Internal)""

Running st_3dintersection on the above configuration fails and causes a core dump in the database. See attached for sample data creation and query scripts.

(This same query works fine on the following configuration: POSTGRES: "PostgreSQL 10.19 (Ubuntu 10.19-0ubuntu0.18.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit" POSTGIS: POSTGIS="2.5.3 r17699" [EXTENSION] PGSQL="100" GEOS="3.7.0-CAPI-1.11.0 673b9939" SFCGAL="1.3.7" PROJ="Rel. 5.2.0, September 15th, 2018" GDAL="GDAL 2.4.0, released 2018/12/14" LIBXML="2.9.4" LIBJSON="0.12.1" RASTER )

[cege]

SQL data creation and query and details of the 2 configurations one which works one doesn't

[robe]

I'm flipping to SFCGAL as it's an sfcgal function. I'll report to SFCGAL once I've confirmed the issue.

[robe]

Okay I just tried this on my system and I don't get a core-dump. So I suspect this issue is fixed in newer SFCGAL.

My install is

POSTGIS="3.2.0dev 3.2.0beta1-18-g085cc7f04" [EXTENSION] PGSQL="140" 
GEOS="3.10.0-CAPI-1.16.0" PROJ="7.2.1" GDAL="GDAL 3.3.3, released 2021/10/25" LIBXML="2.9.9" LIBJSON="0.12" 
LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)" TOPOLOGY RASTER

Although it's puzzling my database doesn't show SFCGAL , but I'm definitely using it becuase if I do

DROP EXTENSION postgis_sfcgal;

and rerun I get ST_3DIntersection does not exist. I know I am running SFCGAL 1.4.0 with CGAL 5.3 since I compiled it myself.

Here is the script I am using, mild revision to use newer syntax.

create table public.buildings (
	building_id serial,
	building_name character varying (200) not null,
    location geometry(geometryZ)
);
CREATE EXTENSION IF NOT EXISTS postgis_sfcgal;
--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-- insert two rows of data

insert into public.buildings
(building_name, location)
values
('Building 1',st_extrude(st_geomfromtext('POLYGON((300 200 0, 300 2200 0, 1600 2200 0, 1600 200 0, 300 200 0))',27700),0,0,600));


--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/* Building 2 */
insert into public.buildings
(building_name,location)
values
('Building 2', st_extrude(st_geomfromtext('POLYGON    ((2000 1200 0, 2000 2700 0, 2800 2700 0, 2800 1200 0, 2000 1200 0))',27700),0,0,600)
);

select a.building_id, b.building_id, ST_AsText(st_3dintersection(a.location, b.location))::varchar(75)
from 
public.buildings a, public.buildings b;

Output is:

building_id | building_id |                                  st_astext
-------------+-------------+-----------------------------------------------------------------------------
           1 |           1 | POLYHEDRALSURFACE Z (((300 200 0,300 2200 0,1600 2200 0,300 200 0)),((1600
           1 |           2 | GEOMETRYCOLLECTION EMPTY
           2 |           1 | GEOMETRYCOLLECTION EMPTY
           2 |           2 | POLYHEDRALSURFACE Z (((2000 1200 0,2000 2700 0,2800 2700 0,2000 1200 0)),((

On my sysem running PostGIS 3.1.4 with SFCGAL 1.4.0 works as well

PostgreSQL 14.1, compiled by Visual C++ build 1914, 64-bitPOSTGIS="3.1.4 3.1.4" [EXTENSION] PGSQL="140" GEOS="3.9.1-CAPI-1.14.1" SFCGAL="1.4.0" PROJ="7.1.1" GDAL="GDAL 3.2.3, released 2021/04/27" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)" RASTER

So if you can I'd suggest you try upgrading to a newer SFCGAL.

[cege]

Hi again

As suggested, I managed to install SFCGAL 1.4.0 and CGAL 5.3 on my server and make install etc. However, I don't want to update PostGIS as this is a live server. Is there an easy way to change the SFCGAL version without doing a full PostGIS update, so that I can test that st_3dintersection issue is resolved ? I've seen Postgis_extensions_upgrade but can't find where I configure PostGIS to detect the new version of sfcgal (or is it simply a question of replacing the library file in the same location as before and the upgrade process will handle the rest?)

thanks

[robe]

Which version of PostGIS are you running? If you are running postgis 3.1 then the postgis-sfcgal is a separate lib file. So it wouldn't impact postgis proper. If it's 3.0 or lower then it's linked into the main postgis-3.so or postgis-2.5.

You shouldn't need to touch PostGIS as I think all the sfcgal functions are delegated to the sfcgal library.

I would check what ldd returns: here is for example an output of an old ubuntu I have

cd /usr/lib/postgresql/11/lib 
ldd postgis-2.5.so

Should output something like

      linux-vdso.so.1 (0x00007fffad1ec000)
        liblwgeom-2.5.so.0 => /usr/lib/liblwgeom-2.5.so.0 (0x00007f564b0ea000)
        libgeos_c.so.1 => /usr/lib/x86_64-linux-gnu/libgeos_c.so.1 (0x00007f564aeb9000)
        libproj.so.12 => /usr/lib/x86_64-linux-gnu/libproj.so.12 (0x00007f564ac50000)
        libjson-c.so.3 => /lib/x86_64-linux-gnu/libjson-c.so.3 (0x00007f564aa45000)
        libprotobuf-c.so.1 => /usr/lib/x86_64-linux-gnu/libprotobuf-c.so.1 (0x00007f564a83c000)
        libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f564a47b000)
        libSFCGAL.so.1 => /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1 (0x00007f5649aad000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f56496bc000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f564931e000)
        libgeos-3.7.1.so => /usr/lib/x86_64-linux-gnu/libgeos-3.7.1.so (0x00007f5648f7b000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5648bf2000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f56489da000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f56487bb000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f56485b7000)
        libicuuc.so.60 => /usr/lib/x86_64-linux-gnu/libicuuc.so.60 (0x00007f56481ff000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f5647fe2000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f5647dbc000)
        libCGAL_Core.so.13 => /usr/lib/x86_64-linux-gnu/libCGAL_Core.so.13 (0x00007f5647b2c000)
        libboost_thread.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.65.1 (0x00007f5647907000)
        libboost_serialization.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_serialization.so.1.65.1 (0x00007f56476c9000)
        libCGAL.so.13 => /usr/lib/x86_64-linux-gnu/libCGAL.so.13 (0x00007f56474aa000)
        libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f5647229000)
        libgmpxx.so.4 => /usr/lib/x86_64-linux-gnu/libgmpxx.so.4 (0x00007f5647023000)
        libmpfr.so.6 => /usr/lib/x86_64-linux-gnu/libmpfr.so.6 (0x00007f5646da3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f564b5dd000)
        libicudata.so.60 => /usr/lib/x86_64-linux-gnu/libicudata.so.60 (0x00007f56451fa000)
        libboost_system.so.1.65.1 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 (0x00007f5644ff5000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5644ded000)

Note the path of below so you want to replace /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1 (or whatever that path is with your new one)

 libSFCGAL.so.1 => /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1 (0x00007f5649aad000)

If you are running postgis-3.1, then you'll probably need to check instead

ldd postgis_sfcgal-3.so 

[cege]

Hi robe

That worked - I simply swapped out the libSFCGAL.so file for the newer one, and then ran select postgis_extensions_upgrade()

st_3dintersection is now working fine, many thanks!