[postgis-tickets] [PostGIS] #5315: ST_Buffer causes segfault

PostGIS trac at osgeo.org
Sun Jan 15 03:18:13 PST 2023


#5315: ST_Buffer causes segfault
----------------------+---------------------
  Reporter:  ewie     |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  medium   |  Milestone:
 Component:  postgis  |    Version:  3.2.x
Resolution:           |   Keywords:
----------------------+---------------------
Description changed by ewie:

Old description:

> 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
> it should not return a geometry that causes ST_Buffer to segfault. 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)"
> }}}

New description:

 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)"
 }}}

--
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5315#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.


More information about the postgis-tickets mailing list