In running make check in 3.2 branch, compile fails thus:
make[3]: *** No rule to make target `capi/GEOSGetCentroidTest.cpp',
needed by `GEOSGetCentroidTest.o'. Stop.
make[2]: *** [check-am] Error 2
Missing rule not committed?
P
On Sat, Apr 17, 2010 at 2:56 PM, strk wrote:
> On Sat, Apr 17, 20
On Sat, Apr 17, 2010 at 10:46:51AM -0700, Paul Ramsey wrote:
> Yes, indeed. This could also be the source of a leak reported a couple
> weeks ago in the otherwise boring centroid function...
Ready for test in r2975.
Mat, could you add your changes in the NEWS file too please ?
--strk;
() Fr
Yes, indeed. This could also be the source of a leak reported a couple
weeks ago in the otherwise boring centroid function...
P
On Sat, Apr 17, 2010 at 8:40 AM, strk wrote:
> As of GEOS r2974 initGEOS works back as it did in 3.0.0,
> that is it will not allocate new memory.
>
> To give you a fig
As of GEOS r2974 initGEOS works back as it did in 3.0.0,
that is it will not allocate new memory.
To give you a figure, calling 'SELECT ST_IsValid(geom) from myTable;'
where myTable contains 120044 geometries resulted in +4Mb of memory
leaking:
definitely lost: 4,801,698 bytes in 120,040 blocks
For the record, I verified that up to 3.0.0
the semantic was indeed NOT to allocate any new
structures, see:
http://trac.osgeo.org/geos/browser/branches/3.0/capi/geos_c.cpp
Thus I think we should go back there.
--strk;
On Sat, Apr 17, 2010 at 01:22:22PM +0200, strk wrote:
> I tought initGEOS(
I tought initGEOS() [ the non-rehentrant version ]
was always returning the same handle, a singleton.
Code reveals that's not the case, which means
old clients (like postgis) end up allocating
lots of contexts and leat them leak.
So, is there any reason not to return a singleton ?
--strk;
()
