[GRASS-dev] Re: IMPORTANT: [GRASS GIS] #837: Memory leaks in r.example

[Hamish]

Glynn wrote:
> Essentially, you don't know whether it's safe to free the mapset
> string returned from G_find_*. If it isn't and you free it, it can
> cause a crash. If it is and you don't free it, you've leaked some
> memory.
> 
> Most of the time this isn't a problem, but the null bitmap code calls
> these functions every NULL_ROWS_INMEM (== 8) rows. For large maps (or
> for large numbers of maps, e.g. r.series), this could add up (even if
> mapset names are short, there's an overhead for each malloc()'d
> block).

for some perspective, what's the maximum damage? what's the typical damage?

as a "worst plausible case" say you have 50,000 x 50,000 cell raster
output from r.sun, and you have 365 of them you want to run them through
r.series.

as a "typical heavy load case" let's say a 4000x4000 cell raster with
a dozen of them to run through r.series.

if the leak is a *mapset string, from your above comments above and the
G_find_file() code that means GMAPSET_MAX (256) bytes+whatever system
overheads that incurs.


for these two cases that would be:

expected worst case:
  50000/8 * 256 * 365 = 570mb

normal heavy load: 
  4000/8 * 256 * 12 = 1.5mb


how's my math?


compare the leak to r.series memory req for that sized map:
 does it keep 8 rows of all maps in memory during processing(??)
 (not sure, but going with that...)

8 rows * 50k columns * sizeof(DCELL) * 365 maps = 570mb

so total mem use at completion = 1.2gb


if all of the above is correct (& I'm not sure it is), then I would say
that anyone running the above worse case is probably running it on a
system which has >2gb ram, & so not a cause for panic.


Hamish