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

GRASS GIS GRASS GIS developer
1

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.

Index: file_name.c

RCS file: /grassrepository/grass/src/libes/gis/file_name.c,v
retrieving revision 1.3
diff -r1.3 file_name.c
30a31

  char *location = G__location_path();

40c41
< sprintf(path,"%s/%s", G__location_path(), xmapset);
---

    sprintf(path,"%s/%s", location, xmapset);

41a43,44

  else if (mapset && *mapset)
    sprintf(path,"%s/%s", location, mapset);

43,46c46
< if (mapset && *mapset)
< sprintf(path,"%s/%s", G__location_path(), mapset);
< else
< sprintf(path,"%s/%s", G__location_path(), G_mapset());
---

    sprintf(path,"%s/%s", location, G_mapset());

47a48,49

  G_free (location);
  

Index: get_row.c

RCS file: /grassrepository/grass/src/libes/gis/get_row.c,v
retrieving revision 1.8
diff -r1.8 get_row.c
1025c1025
< static char *name=NULL, *mapset=NULL;
---

   static char *name=NULL, *mapset=NULL, *dummy;

1042c1042
< if (G_find_file(dir_name, NULL_FILE, mapset)==NULL)
---

   if ((dummy = G_find_file(dir_name, NULL_FILE, mapset))==NULL)

1050c1050,1051
<
---

   G_free (dummy);
   

Index: open.c

RCS file: /grassrepository/grass/src/libes/gis/open.c,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 open.c
92c92
< char xname[512], xmapset[512];
---

    char xname[512], xmapset[512], *dummy;

109c109
< if (! G_find_file (element, name, mapset))
---

  if ((dummy = G_find_file (element, name, mapset)) == NULL)

110a111

  G_free (dummy);

--
Eric G. Miller <egm2@jps.net>

2

Why gmakelinks5 when run in a specific directory link all grass
modules rather than the module involve in the specific directory
as does gmake5?

--
Robert Lagacé, professeur
Pavillon Comtois
Université Laval
Ste-Foy, Québec, G1K 7P4
tel : (418)-656-2131#2276
Fax : (418)-656-3723
E-mail : lagace@grr.ulaval.ca

3

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 :frowning:
>
> 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@virgin.net>