Opened 2 years ago
Last modified 2 years 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 )
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)"
Note:
See TracTickets
for help on using tickets.