[GRASS5] Re: r.sunmask - memory leakage in GRASS lib

[Glynn Clements]

Markus Neteler wrote:

> > > A C related question (sorry, I am geographer only):
> > > 
> > > > RCS file: /grassrepository/grass/src/libes/gis/file_name.c,v
> > > > > 	char *location = G__location_path();
> > > [...]
> > > > > 	G_free (location);
> > > 
> > > Is it always required to write GRASS functions which output characters in
> > > return code to a variables and G_free() this variable later?
> > > 
> > > If so, many leakages will be there in GRASS :-(
> > 
> > It's not consistent.  Some functions return pointers to a static buffer
> > or other memory that shouldn't be free'ed by the caller.  Many return
> > dynamic memory.  It is a real problem.  For most modules, it doesn't
> > matter too much; a few char buffers are leaked, but usually the memory
> > is fairly insignificant.  But, in this case, it's library functions
> > calling other library functions (perhaps repeatedly) and they need to be
> > very careful.  I'm certain I did not find all occurences of library
> > functions not being careful about memory.
> > 
> > While I was messing about, I did wonder if we could plug in something
> > like the Boehm Conservative Garbage collector for G_malloc/G_calloc.  I
> > don't have any experience with these things, and I understand it can be
> > problematic with lots of pointers being passed around to the same chunk
> > of memory (I don't know).  Just a thought...
> 
> Probably a good idea! Anyone out there familiar with such stuff?

Don't go there.

Automated garbage collection is necessary if you're writing a
high-level language; the rest of the time, it just isn't worth the
effort.

Given that the majority of GRASS programs are short-lived, memory
leaks aren't an issue most of the time. A typical GRASS program can
happily allocate all of its memory dynamically and never free any of
it.

Library functions need to be written so that memory leaks are
preventable (in case they are used in long-lived programs). They don't
need to make them impossible; in the few cases where a program
actually needs to conserve memory, the program itself should be
responsible for freeing dynamically-allocated memory.

BTW, it should be pointed out that conservative GC guarantees that
memory leaks will occur. Consequently, it's not suitable for
long-lived programs.

Long lived programs need "exact" GC, which requires the entire system
to be structured in such a way that the GC can automatically enumerate
all references to dynamically allocated memory. This imposes a
significant burden on the code structure (e.g. the GC must know the
details of every data structure which can form part of the reference
tree).

-- 
Glynn Clements <glynn.clements at virgin.net>