PostGIS

I experienced this in a real-world query, but a short reproducible test case of pgsql2shp segfault is below. I think the problem may be state->message overflowing with messages about the truncated columns. As a workaround, raising SHPLOADERMSGLEN ... [More] from 1024 to 8192 caused pgsql2shp to complete successfully. But I assume some bounds checking is needed to prevent the overflow from occurring in the first place. This is against 2.5.3. Sorry to report against an old version, but I did not find a bug report for this against any newer version either. gdb --args ./pgsql2shp -p 5434 -f test.shp dfuhry 'SELECT 1 AS abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk, 2 AS bcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijkl, 3 AS cdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklm, 4 AS defghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmn, 5 as efghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmno, 6 AS fghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnop, 7 AS ghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopq, 8 AS hijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqr, 9 AS ijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrs, 10 AS jklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst' ... (gdb) r ... Initializing... *** buffer overflow detected ***: terminated Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff7d74537 in __GI_abort () at abort.c:79 #2 0x00007ffff7dcd768 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7edbc24 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155 #3 0x00007ffff7e5c652 in __GI___fortify_fail (msg=msg@entry=0x7ffff7edbbba "buffer overflow detected") at fortify_fail.c:26 #4 0x00007ffff7e5b050 in __GI___chk_fail () at chk_fail.c:28 #5 0x00007ffff7e5a999 in __strncat_chk (s1=, s1@entry=0x55555559b068 "Warning, field abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk renamed to ABCDEFGHIJ\nWarning, field bcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijkl renamed to BCDEFGHIJ"..., s2=, s2@entry=0x7fffffffdd00 "No geometry column found.\nThe DBF file will be created but not the shx or shp files.\n", n=, s1len=, s1len@entry=1024) at strncat_chk.c:33 #6 0x0000555555562c11 in strncat (__len=, __src=0x7fffffffdd00 "No geometry column found.\nThe DBF file will be created but not the shx or shp files.\n", __dest=0x55555559b068 "Warning, field abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk renamed to ABCDEFGHIJ\nWarning, field bcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijkl renamed to BCDEFGHIJ"...) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:136 #7 ShpDumperOpenTable (state=state@entry=0x55555559afb0) at pgsql2shp-core.c:1837 #8 0x000055555555774f in main (argc=, argv=) at pgsql2shp-cli.c:191 [Less]

07:15:51 ./topology/test/regress/st_changeedgegeom .. failed (diff expected obtained: /tmp/pgis_reg/test_188_diff) 07:15:52 ----------------------------------------------------------------------------- 07:15:52 --- ... [More] ./topology/test/regress/st_changeedgegeom_expected 2022-03-04 04:03:00.146712501 -0800 07:15:52 +++ /tmp/pgis_reg/test_188_out 2022-03-04 04:15:52.314253246 -0800 07:15:52 @@ -1,4 +1,4 @@ 07:15:52 -T1|Edge 25 changed 07:15:52 +ERROR: Geometry type (Point) does not match column type (Polygon) 07:15:52 ERROR: SQL/MM Spatial exception - start node not geometry start point. 07:15:52 ERROR: SQL/MM Spatial exception - end node not geometry end point. 07:15:52 ERROR: SQL/MM Spatial exception - geometry crosses a node 07:15:52 @@ -8,31 +8,32 @@ This started happening [c273f394/git] [Less]

Right now berrie is failing on topology tests (which I will ticket later) and so is berrie64. However berrie is showing green and berrie64 is showing error. This is because berrie goes on to run garden tests which succeed. She should be stopping upon first failure.

next_left_edge is mentioned a the docs for AddFace and Polygonize in the topology documentation. For instance in ​https://postgis.net/docs/TopologyPolygonize.html it says "Note: This function does not use nor set the next_left_edge and ... [More] next_right_edge fields of the edge table." However there is no documentation of what 'next_left_edge' means and what it does. The user is left without any way of figuring out what the consequences of that note are. [Less]

Recently I performed a reposync for the postgresql yum repo (​https://yum.postgresql.org/11/redhat/rhel-8-x86_64/). On completing, it was found that new packages had been downloaded, but closer inspection revealed that they had not been signed ... [More] with the appropriate GPG key: postgis30_11-3.0.5-1.rhel8.x86_64.rpm: digests OK postgis30_11-client-3.0.5-1.rhel8.x86_64.rpm: digests OK postgis30_11-devel-3.0.5-1.rhel8.x86_64.rpm: digests OK postgis30_11-docs-3.0.5-1.rhel8.x86_64.rpm: digests OK postgis30_11-gui-3.0.5-1.rhel8.x86_64.rpm: digests OK postgis30_11-utils-3.0.5-1.rhel8.x86_64.rpm: digests OK These packages need to be signed and uploaded to the repo again so that it is possible to check the integrity of the packages using rpm and the appropriate GPG key. [Less]

Spin-off of #5105, ST_Area can report non-zero area for completely flat polygons. Example: POLYGON(( 29.262792863298348 71.22115103790775, 29.26598031986849 71.22202978558047, 29.275379947735576 71.22044935739267, 29.29461024331857 ... [More] 71.22741507590429, 29.275379947735576 71.22044935739267, 29.26598031986849 71.22202978558047, 29.262792863298348 71.22115103790775 )) Note how the polygon ring is going forward and backward onto the exact same vertices. [Less]

Spin-off of #5105, ST_Area can report non-zero area for completely flat polygons. Example: POLYGON(( 29.262792863298348 71.22115103790775, 29.26598031986849 71.22202978558047, 29.275379947735576 71.22044935739267, 29.29461024331857 ... [More] 71.22741507590429, 29.275379947735576 71.22044935739267, 29.26598031986849 71.22202978558047, 29.262792863298348 71.22115103790775 )) Note how the polygon ring is going forward and backward onto the exact same vertices. [Less]

A statement like the following results in ValidateTopology? returning invalidities, while starting with a found-valid state: begin; select TopoGeo_addLineString('test', ST_Translate(geom, 2, 1)) from ( select * from test.edge where edge_id >= ... [More] 720000 and edge_id < 730000 order by edge_id ) foo; select * from ValidateTopology('test'); The last ValidateTopology? call reports 147 face has multiple shells invalidities, all reporting face 0 as having such state. [Less]

At least in this test case, more info found here ​https://github.com/larsop/resolve-overlap-and-gap/issues/23 . The problem is the same on POSTGIS="3.3.0dev 3.1.0alpha2-1416-ged023e8ff" [EXTENSION] PGSQL="120" GEOS="3.9.0-CAPI-1.16.2" ... [More] PROJ="7.2.1" LIBXML="2.9.10" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)" TOPOLOGY and POSTGIS="3.1.1 aaf4c79" [EXTENSION] PGSQL="120" GEOS="3.9.0-CAPI-1.16.2" PROJ="7.2.1" LIBXML="2.9.10" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)" TOPOLOGY [Less]

A statement like the following results in ValidateTopology? returning invalidities, while starting with a found-valid state: begin; select TopoGeo_addLineString('test', ST_Translate(geom, 2, 1)) from ( select * from test.edge where edge_id >= ... [More] 720000 and edge_id < 730000 order by edge_id ) foo; select * from ValidateTopology('test'); The last ValidateTopology? call reports 147 face has multiple shells invalidities, all reporting face 0 as having such state. [Less]