[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