[postgis-users] ST_AsSVG crashes with large/complex geometries

[Mike Leahy]

Hi Mark,

Sorry for the delay - I've been on the road a bit.  I've got 
postgresql-8.3.6, and postgis-1.3.5, both installed from the Fedora 10 
repos.

I'll report this as a bug sometime in the next few days when I have a 
bit of time to put a sample together...unless anyone has any other 
suggestions?

Mike

> Message: 22
> Date: Thu, 19 Feb 2009 14:18:16 +0000
> From: Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk>
> Subject: Re: [postgis-users] ST_AsSVG crashes with large/complex
> 	geometries
> To: mgleahy at alumni.uwaterloo.ca,	PostGIS Users Discussion
> 	<postgis-users at postgis.refractions.net>
> Message-ID: <499D6A28.5080102 at siriusit.co.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Mike Leahy wrote:
> 
>> > Hello list,
>> > 
>> > I'm wondering if anyone has run into issues with st_assvg locking up 
>> > postgresql.  I have an application that generates svg from unioned sets 
>> > of geometries.  So far it has been working pretty well, except I just 
>> > tested it with very large sets of geometries, and it invariably locks up 
>> > the backend database without any errors etc.  I could send a sample 
>> > geometry if that would help, but I think this can probably be done with 
>> > any dataset.  I've verified that the problem is not with st_union, as it 
>> > outputs a geometry just fine...it's only when it gets to st_assvg does 
>> > it freeze things...there is no CPU activity.  I do see this in the pg_log:
>> > 
>> > *** glibc detected *** postgres: postgres testdb [local] SELECT: 
>> > realloc(): invalid next size: 0x000000000220f410 ***
>> > 
>> > Am I just expecting too much of the st_assvg function, or is this 
>> > something that might be fixable?
>> > 
>> > Thanks for any advice,
>> > Mike
> 
> 
> Hi Mike,
> 
> Yeah, that sounds like a bug. What versions of PostgreSQL/PostGIS are 
> you using? You may want to open a bug with a sample geometry on the 
> PostGIS bugtracker.
> 
> 
> ATB,
> 
> Mark.