[postgis-devel] Re: [postgis-users] Performance and memory problems

[David Blasby]

strk wrote:
> dblasby wrote:
> 
>>So, what is the multi-geometry it's failing on?
> 
> 
> Following is the multi-geometry.
> 
> Note though: once I made GEOS2POSTGIS print it (GEOSasText) I got no 
> segfault anymore. If I add a line of code anywere the segfault is back !
> I've had similar experiences with postgresql, and it's very frustrating...
> 
> What I remember from my previous experiences (they were trumatic so
> its not much) is that uninitialized/unallocated memory was being used
> and it was randomly available because of postgresql memory pool mechanism.
> It would be helpful having a way to tell postgresql to always free
> pfree'd memory (like the FORCE_NEW thing for libstdc++). Any hint on this ?
> 
>  SRID=30001;GEOMETRYCOLLECTION(LINESTRING(709096.216508478 160373.930761042,709128.867292722 160363.047166294),LINESTRING(709128.867292722 160363.047166294,709138.068877372 160339.597966701),LINESTRING(709138.068877372 160339.597966701,709124.612796593 160331.880508607),LINESTRING(709124.612796593 160331.880508607,709081.276301142 160334.94770349),LINESTRING(709081.276301142 160334.94770349,709056.936625615 160327.329187167),POLYGON((709068.269935615 160376.406104325,709069.106463379 160377.393723007,709068.269935615 160376.406104325,709068.269935615 160376.406104325)),POLYGON((709077.883676116 160376.272546198,709096.216508478 160373.930761042,709077.883676116 160376.272546197,709077.883676116 160376.272546198)),POLYGON((709047.624998362 160348.638487995,709046.64668149 160350.87732853,709047.624998362 160348.638487997,709047.624998362 160348.638487995)))
> 
> 
> 
>>I dont think this is a recursion problem - it shouldnt be recursing to a 
>>depth more than 2 (the original multi* and the sub-component it's 
>>working on).
>>
>>It most likely that there's a problem with the collector function or 
>>that GEOS is giving back garbage.
> 
> 
> Consider that removing the pfree() call puts everything back
> in a working state. 

The pfree() is just showing us the problem - the actual problem happened 
before the pfree().  This is one of the things that I hate about C (as 
opposed to java).

Your best bet will probably be to run postgresql in valgrind and see 
where the memory is screwed with.

Also, is this a problem with intersect?

What do these queries do:

SELECT buffer(<bad geometry>,0) ;

and

SELECT geomunion(<bad geometry>,<bad geometry>);

If these things work, then there's probably a bug in 
make_oneobj_geometry() or add_to_geometry().  There are also 
memory-alignment issues (intel machines are 4 byte aligned and sparcs 
are 8 byte aligned) - I recently fixed a bug in of those two functions 
regarding alignment issues.

You could also try under solaris as it tends to segfault as soon as you 
make a memory management mistake (linux tends to keep going for a while).

dave