[postgis-devel] Geos_noop memory leak?

[Markus Schaber]

Hi, strk,

strk at refractions.net schrieb:

>>I think I might have found a memory leak in geos_noop.
> 
> GEOSnoop does nothing but converting geometries:
> PostGIS->GEOS->PostGIS
>
> If it leaks then *all* geos functions will leak.

That's bad. I initially thought there may be some missing deallocation
in geosnoop().

> If you're using GNU's libstdc++ >= 3.0 try setting
> GLIBCPP_FORCE_NEW=1 in the environment, this would
> disable late-deallocation, which is a *feature* of 
> the library.
Hmm, I have:

/usr/lib/gcc-lib/i486-linux/3.3.5/libstdc++.so
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
/usr/lib/libstdc++-libc6.1-1.so.2
/usr/lib/libstdc++-libc6.2-2.so.3
/usr/lib/libstdc++.so.5
/usr/lib/libstdc++.so.5.0.7
/usr/lib/libstdc++.so.6
/usr/lib/libstdc++.so.6.0.3

I tried your setting in postmaster.env (which is proved to get passed to
postmaster because I use it to set additional PGDATA directories),
however, the leak still seems to exist.

When using \connect to go to a different database, the memory comes
back. Even using \connect to reconnect to the same database, the memory
is freed. This may be due to some radical cleanup of all allocated memory.

There is no difference whether I use autocommit, or BEGIN/COMMIT or
BEGIN/ABORT.

I tried to find a short query that illustrates the problem. The
following query does leak about 10M on every call on my machine (i386):

select npoints(buffer('POINT(0 0)',1,100000));

Note that the npoints() is just to avoid sending this much output to the
client. I also tried the example on 0.9 which seems not to suffer from
this problem.

HTH,
Markus

-- 
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios at logi-track.com | www.logi-track.com