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 colivier, 10 years ago

Resolution: fixed
Status: newclosed

Done as r12361 for trunk and r12362 for 2.1 branch

comment:2 by strk, 10 years ago

Resolution: fixed
Status: closedreopened

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 pramsey, 10 years ago

Milestone: PostGIS 2.1.2PostGIS 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 strk, 10 years ago

Resolution: fixed
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.