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

[strk]

dblasby wrote:
> 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

valgrind on postgres with palloc/pfree/repalloc made macros
to malloc/free/realloc suggests a problem in add_to_geometry.

I'm not familiar with memory alignment issues and I've not access
to a solaris system. I'll try on this anyway. If you can give me
an overall look about that it will be easier.

TIA

--strk;