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

[Markus Neteler]

Eric,

(cc to GRASS 5)

On Wed, Jun 13, 2001 at 06:04:09PM -0700, Eric G. Miller wrote:
> On Wed, Jun 13, 2001 at 04:07:12PM +0100, Markus Neteler wrote:
> > Eric,
> > 
> > On Mon, Jun 11, 2001 at 10:32:26PM -0700, Eric G. Miller wrote:
> > > Here's a diff that fixes all the significant leakages in libgis (from
> > > r.sunmask's point of view).  I'm sure there are quite a few still in
> > > there.
> > 
> > it *seems* that the leakage in r.sunmask is fixed. But the machine will
> > run some more 5h to finish the map. r.sunmask is incredible slow with
> > FP maps!
> 
> I only tested it on a very small map (float) so it didn't take but a
> couple minutes.  I'm not even sure I understand what r.sunmask is trying
> to do (with my test map, I got an output raster of mostly -1 values with
> a few 1 values -- maybe my test map has weird values to begin with).

congrats, the r.sunmask runs through now...!
The idea of this module is to calculate cast shadow areas from DEM or
buildings or whatever. You specify
 - either the sun position directly (if you know)
 - or specify location, date, time, etc and let r.sunmask calc. the sun
   position for you

Then the shadow maps is written,  null() where is no shadow and 1 where
is shadow.

> > 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?

Regards and thanks again for the leakage detection and fixing
(thanks to Justin and Huidae as well!)

 Markus