Opened 10 years ago
Closed 10 years ago
#2681 closed defect (fixed)
GML error
Reported by: | colivier | Owned by: | colivier |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.1.4 |
Component: | postgis | Version: | 2.1.x |
Keywords: | GML | Cc: |
Description
SELECT ST_GeomFROMGML('<gml:MultiSurface>
<gml:surfaceMember>
<gml:Surface>
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:LinearRing>
<gml:posList>0 0 0 1 1 1 1 0 0 0</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</gml:Surface>
</gml:surfaceMember> <gml:surfaceMember>
<gml:Surface>
<gml:patches>
<gml:PolygonPatch>
<gml:interior>
<gml:LinearRing>
<gml:posList>0.25 0.25 0.25 0.75 0.75 0.75 0.75 0.25 0.25 0.25</gml:posList>
</gml:LinearRing>
</gml:interior>
</gml:PolygonPatch>
</gml:patches>
</gml:Surface>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Surface>
<gml:patches>
<gml:PolygonPatch>
<gml:exterior>
<gml:LinearRing>
<gml:posList>0 0 0 -1 -1 -1 -1 0 0 0</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:PolygonPatch>
</gml:patches>
</gml:Surface>
</gml:surfaceMember>
</gml:MultiSurface>');
Thanks to Even.
Change History (4)
comment:1 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 10 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I've seen the backend crash with 2.1.2dev:
DETAIL: Failed process was running: SELECT 'surface_23', ST_AsEWKT(ST_GeomFromGML('<gml:Surface><gml:patches><gml:PolygonPatch><gml:interior><gml:LinearRing><gml:coordinates>1,2 3,4 5,6 1,2</gml:coordinates></gml:LinearRing></gml:interior></gml:PolygonPatch></gml:patches></gml:Surface>'));
Worth double-checking this under valgrind. Best if a test exists for cunit, otherwise see pramsey's blog post on out to valgrind postgresql
comment:3 by , 10 years ago
Milestone: | PostGIS 2.1.2 → PostGIS 2.1.3 |
---|
I'm rolling this forward. What needs to happen is (a) in trunk the GML code needs to move into liblwgeom (b) once there it need to be valground © once fixes for any memory issues are isolated, they can be back-ported into 2.1 branch.
comment:4 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
I've checked with valgrind with the full database running and I saw no problems. I guess the crash I saw was due to an unclean rebuild (very likely in 2.1 branch as deps are not clearly encoded there).
Moving the support to liblwgeom would still be nice, but it's for another ticket.
Done as r12361 for trunk and r12362 for 2.1 branch