Opened 16 months ago

Last modified 15 months ago

#5315 closed defect

ST_Buffer causes segfault — at Version 1

Reported by: ewie Owned by: pramsey
Priority: blocker Milestone: PostGIS 3.0.9
Component: postgis Version: 3.2.x
Keywords: Cc: ewie

Description (last modified by ewie)

The following query causes a segfault that puts Postgres in recovery mode:

SELECT
  ST_Buffer(
    ST_Transform(
      ST_SetSRID(
        ST_GeomFromText(
          'MULTIPOLYGON(((0 0, 1 0, 1 1, 0 1, 0 0)))',
          4326
        ),
        4647
      ),
      25832
    ),
    1
  );

Postgres log:

2023-01-14 01:21:54.455 CET [4520] LOG:  server process (PID 5016) was terminated by exception 0xC0000005
2023-01-14 01:21:54.455 CET [4520] DETAIL:  Failed process was running: SELECT
	  ST_Buffer(
	    ST_Transform(
	      ST_SetSRID(
	        ST_GeomFromText(
	          'MULTIPOLYGON(((0 0, 1 0, 1 1, 0 1, 0 0)))',
	          4326
	        ),
	        4647
	      ),
	      25832
	    ),
	    1
	  );
2023-01-14 01:21:54.455 CET [4520] HINT:  See C include file "ntstatus.h" for a description of the hexadecimal value.
2023-01-14 01:21:54.455 CET [4520] LOG:  terminating any other active server processes
2023-01-14 01:21:54.462 CET [8804] WARNING:  terminating connection because of crash of another server process
2023-01-14 01:21:54.462 CET [8804] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2023-01-14 01:21:54.462 CET [8804] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2023-01-14 01:21:54.476 CET [4520] LOG:  all server processes terminated; reinitializing
2023-01-14 01:21:54.665 CET [5368] LOG:  database system was interrupted; last known up at 2023-01-14 01:01:08 CET
2023-01-14 01:22:29.148 CET [4480] FATAL:  the database system is in recovery mode
2023-01-14 01:22:50.260 CET [5368] LOG:  database system was not properly shut down; automatic recovery in progress
2023-01-14 01:22:50.440 CET [5368] LOG:  redo starts at 157/4F24D0F8
2023-01-14 01:22:50.441 CET [5368] LOG:  invalid record length at 157/4F24D1E0: wanted 24, got 0
2023-01-14 01:22:50.441 CET [5368] LOG:  redo done at 157/4F24D1A8
2023-01-14 01:22:50.891 CET [4520] LOG:  database system is ready to accept connections

The segfault is caused by ST_Buffer. Omitting ST_Buffer or calling it with buffer_or_radius=0 causes no segfault.

Calling ST_SetSRID with srid=4647 before ST_Transform is nonsense but ST_Buffer should not segfault on the resulting geometry. The origin of this query is a database user who erroneously set incorrect SRID 4647 before transforming geometries.

I cannot reproduce it with Docker images postgis/postgis:12-3.2 or postgis/postgis:14-3.3.

Postgres & PostGIS versions

PostgreSQL 12.13, compiled by Visual C++ build 1914, 64-bit

POSTGIS="3.2.2 3.2.2" [EXTENSION] PGSQL="120" GEOS="3.10.3-CAPI-1.16.1" SFCGAL="1.4.1" PROJ="7.2.1" GDAL="GDAL 3.4.2, released 2022/03/08 GDAL_DATA not found" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)" RASTER
PostgreSQL 14.6, compiled by Visual C++ build 1914, 64-bit

POSTGIS="3.3.2 3.3.2" [EXTENSION] PGSQL="140" GEOS="3.11.1-CAPI-1.17.1" PROJ="7.2.1" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)"

Change History (1)

comment:1 by ewie, 16 months ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.