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

Markus Metz markus.metz.giswork at googlemail.com
Fri Apr 17 09:52:08 EDT 2009


Glynn Clements wrote:
> 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.
>   
> Single-instance allocations don't need to be free()d; they can remain
> until the process terminates.
>
> Explicitly freeing memory when termination is imminent is a waste of
> resources (e.g. CPU cycles, and I/O bandwidth in the case where free()
> causes swapped-out memory to be swapped back in). It's colloquially
> referred to as "rearranging the deckchairs on the Titanic".
>   
Clear enough, thanks for the example!
>   
>>
>> 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?

Markus M


More information about the grass-dev mailing list