[postgis-devel] memory leak in converting foramts

[Mark Cave-Ayland]

Paul Ramsey wrote:

>> I have two questions about postgis:
>>
>> 1. Postgis  src code has divided into liblwgeom and postgis two components
>> where liblwgeom is an abstract lib and postgis is relevant to postgresql.
>> However, some functions such as **simplify2d_lwgeom **(in
>> postgis\lwgeom_functions_analytic.c) I  think should be a part of
>> liblwgeom(as the name of  src file) rather than in postgis. Is it designed
>> to be this or  is it will be refined in the future?
> 
> Originally, *all* code was together in the postgis directory. In 1.4
> it was somewhat separated. There is lots of work left to do to create
> a clean separation.

Indeed. Due to the way in which everything was intertwined together, a 
few compromises had to be made during the initial split to stop the work 
  level going exponential. But yes, anything that is abstract of 
PostgreSQL should be in liblwgeom - patches welcome of course :)

>> 2. Functions for converting formats may cause memory leak:
>> For example : ** lwgeom_from_ewkt **, the call stack is :
>> ----------------------------------------------------------------------------
> 
> Because everything runs in the PgSQL context right now, memory leaks
> don't leak (they leak into the PgSQL function call memory context,
> usually, so they are cleaned up almost instantaneous as the function
> call ends), so we've probably got lots of them.
> 
> These two issues, the lack of a complete clean library and the fact
> that the library has never been subjected to any kind of memory
> purification makes liblwgeom still a pretty iffy proposition as a
> standalone geometry library.

There is definitely some work to be done in this area; I'm beginning to 
wonder if we shouldn't have our own hierarchical memory management 
implementation as part of the 2.0 work to solve this. Also a more sane 
API would help too - there are several constructors either without or 
with an asymmetrical deconstructor, for example. But I wouldn't say that 
its use as a standalone library is completely useless.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs