Can't unparse (to wkt or wkb) polygon with missing end point

[pramsey]

I managed to load this into 1.4 using the 1.3 shp2pgsql utility (so the parser accepted it). And now I can't dump the table because this geometry won't unparse. Fortunately, the GML output is more forgiving:

<gml:MultiPolygon srsName="EPSG:2270">
 <gml:polygonMember>
  <gml:Polygon>
   <gml:outerBoundaryIs>
    <gml:LinearRing>
     <gml:coordinates>
      4280509.572796883992851,250062.898095423181076,1384.223139199977595 
      4280509.572796883992851,250062.898095423181076,1384.223139199977595  
      4280509.572796883992851,250062.898095423181076,1384.223139199977595
     </gml:coordinates>
    </gml:LinearRing>
   </gml:outerBoundaryIs>
  </gml:Polygon>
 </gml:polygonMember>
</gml:MultiPolygon>

It's a three-point polygon where startpoint = midpoint = endpoint.

[pramsey]

Here's the backtrace when the unparser hits this kind of case:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000004
0x00280a7c in pfree (pointer=0x855190) at mcxt.c:591
591		(*header->context->methods->free_p) (header->context, pointer);
(gdb) bt
#0  0x00280a7c in pfree (pointer=0x855190) at mcxt.c:591
#1  0x00776163 in output_wkb_polygon_ring_collection (geom=0x12657c2 "", func=0x775e50 <output_wkb_point>) at lwgunparse.c:882
#2  0x00776242 in output_wkb_polygon_collection (geom=0x855190 "??\020~#OPA??f???\017A\"??D\r??@?????????Q?") at lwgunparse.c:894
#3  0x00775f3a in output_wkb_collection (geom=0x126575e "\003", func=0x776220 <output_wkb_polygon_collection>) at lwgunparse.c:797
#4  0x007764c5 in output_wkb (geom=0x126575a "\001") at lwgunparse.c:971
#5  0x00775f3a in output_wkb_collection (geom=0x1265759 "3\001", func=0x776350 <output_wkb>) at lwgunparse.c:797
#6  0x007764c5 in output_wkb (geom=0x1265755 "\001") at lwgunparse.c:971
#7  0x00776635 in unparse_WKB (lwg_unparser_result=0xbfffed0c, serialized=0x1265740 "?\033y?J?\034}H\034y?J?\034}H?\b", alloc=0x772e50 <lwalloc>, free=0x772e90 <lwfree>, flags=7, endian=-1 '?', hex=1 '\001') at lwgunparse.c:1055
#8  0x0076c8ea in serialized_lwgeom_to_hexwkb (lwg_unparser_result=0x855190, serialized=0x855190 "??\020~#OPA??f???\017A\"??D\r??@?????????Q?", flags=8737168, byteorder=4294967295) at lwgeom.c:716
#9  0x00747be7 in LWGEOM_out (fcinfo=0x855190) at lwgeom_inout.c:102
#10 0x00268aa6 in FunctionCall1 (flinfo=0x855190, arg1=0) at fmgr.c:1254
#11 0x00269d45 in OutputFunctionCall (flinfo=0x855190, val=8737168) at fmgr.c:1887
#12 0x000b2202 in CopyOneRowTo (cstate=0x83b840, tupleOid=<value temporarily unavailable, due to optimizations>, values=0x83c3c8, nulls=0x84fbf8 "") at copy.c:1488
#13 0x000b2b47 in DoCopyTo (cstate=0x83b840) at copy.c:1402
#14 0x000b4212 in DoCopy (stmt=0x833690, queryString=0x832c18 "COPY medford.buildings (gid, layer, elevation, shape_leng, shape_area, the_geom) TO stdout;\n") at copy.c:1148
#15 0x001af008 in ProcessUtility (parsetree=0x833690, queryString=0x832c18 "COPY medford.buildings (gid, layer, elevation, shape_leng, shape_area, the_geom) TO stdout;\n", params=0x0, isTopLevel=1 '\001', dest=0x32bd4c, completionTag=0xbffff5ce "") at utility.c:712
#16 0x001ad078 in PortalRunUtility (portal=0x32bd4c, utilityStmt=0xbffff5ce, isTopLevel=1 '\001', dest=0x855190, completionTag=0x855190 "??\020~#OPA??f???\017A\"??D\r??@?????????Q?") at pquery.c:1173
#17 0x001ad24b in PortalRunMulti (portal=0x84a618, isTopLevel=1 '\001', dest=0x32bd4c, altdest=0x32bd4c, completionTag=0xbffff5ce "") at pquery.c:1266
#18 0x001adbc1 in PortalRun (portal=0x84a618, count=2147483647, isTopLevel=1 '\001', dest=0x32bd4c, altdest=0x32bd4c, completionTag=0xbffff5ce "") at pquery.c:813
#19 0x001a86b5 in exec_simple_query (query_string=0x832c18 "COPY medford.buildings (gid, layer, elevation, shape_leng, shape_area, the_geom) TO stdout;\n") at postgres.c:1004
#20 0x001aa424 in PostgresMain (argc=1, argv=0x500524, username=0x500630 "pramsey") at postgres.c:3631
#21 0x00123f3f in main (argc=3, argv=0x500520) at main.c:186

[pramsey]

Small test case to reproduce.

medford=# create table foo (g geometry);
CREATE TABLE
medford=# insert into foo values ('01060000C00100000001030000C00100000003000000E3D9107E234F5041A3DB66BC97A30F4122ACEF440DAF9440FFFFFFFFFFFFEFFFE3D9107E234F5041A3DB66BC97A30F4122ACEF440DAF9440FFFFFFFFFFFFEFFFE3D9107E234F5041A3DB66BC97A30F4122ACEF440DAF9440FFFFFFFFFFFFEFFF');
INSERT 0 1
medford=# select npoints(g) from foo;
 npoints 
---------
       3
(1 row)
medford=# select astext(g) from foo;
// boom

[mcayland]

This should now be fixed in SVN, in that instead of crashing the backend, the unparser correctly returns an error. Interestingly enough, this opens up another question related to the parser validity checks - what do we do if there is already an invalid geom in the database?

ATB,

Mark.

[strk]

Please see also #411. This can't be the correct fix. No way to recover the 'invalid in db' case, and shp2pgsql still allows these shapes to get in (as of current 2.0.0SVN)

[strk]

This is ready for testing again in branches 1.4, 1.5 and trunk. I couldn't reproduce the crash myself (but could have been lucky..)

Crash testers please step up for testing. I'm going to re-close this.