[GRASS-dev] v.net.visibility memory leak? - was Re: [GRASS-user] traveling salesman problem in air

Glynn Clements glynn at gclements.plus.com
Sat Apr 18 16:28:24 EDT 2009


Markus Metz wrote:

> >> I remember a discussion in the dev ml, I think with the osgeo4w 
> >> installer, that memory allocated with malloc/calloc/realloc should be 
> >> free-d with free, not G_free. If this is the case, then there is a 
> >> problem in the vector libs, because space for a struct line_pnts * is 
> >> allocated with calloc and free-d with G_free, and relevant (or all) 
> >> calls to malloc/calloc/realloc/free in diglib should be replaced with 
> >> G_malloc etc. What to do?
> >>     
> >
> > GRASS code should always use the G_* versions unless there is a clear
> > reason not to, e.g. if the pointer will be passed to an external
> > library which will assume ownership of it.
> 
> OK, so lib/vector/diglib needs to be updated. What about dglib and 
> rtree? AFAICT they are written such that the code can be used as 
> external standalone libraries and not a single G_*() version is used, I 
> think.

Two choices: either rewrite the libraries to use the G_* versions, or
ensure that their callers use free() for pointers returned from those
libraries (if the callers only use deallocation functions provided by
the libraries, this point is moot).

The choice would be influenced by whether the library is available
elsewhere, and if so the extent to which the GRASS version has been
modified, and whether the library requires the caller to allocate or
free memory.

For an unmodified (or minimally modified) version of an external
library which performs all allocation and deallocation itself, I would
leave it using malloc() and free().

If the library isn't available elsewhere, or has been heavily
modified, or it requires the caller to allocate and/or free memory, I
would modify it to use the G_* versions.

> >> If Vect_set_release_support() does not cause a severe time penalty, I 
> >> would recommend to use it. IMHO 73,854,014 - 444,026 (previous result) 
> >> bytes = ca. 70 MB lingering around in memory is a bit unnecessary.
> >
> > That should only be done if vectors will be closed signficantly prior
> > to termination, e.g.:
> >
> > 	for (i = 0; i < nvects; i++) {
> > 		vect = Vect_open_old(...);
> > 		...
> > 		Vect_close(vect);
> > 	}
> 
> Can we add this to the Programmer's manual under GRASS 6 Vector 
> Architecture where Vect_set_release_support() is mentioned or have I 
> missed something?

That would be a good idea, IMHO.

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list