[GRASS-dev] [GRASS GIS] #1030: r.li.* memory leak + patch

#1030: r.li.* memory leak + patch
---------------------+------------------------------------------------------
Reporter: neteler | Owner: grass-dev@lists.osgeo.org
     Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Keywords: | Platform: All
      Cpu: All |
---------------------+------------------------------------------------------
Hi,

I get some troubles when working on a (e.g.,) 1700 x 2500 map with
r.li.patchdensity, it swaps
like crazy on a 18GB RAM machine... eventually the processes crash.

Apparently there is memory leak (GRASS 6.4):

{{{
==30423== 826,105,500 bytes in 83,445 blocks are definitely lost in loss
record 49 of 49
==30423== at 0x4C21167: calloc (vg_replace_malloc.c:418)
==30423== by 0x4E3A0B7: G__calloc (alloc.c:74)
==30423== by 0x4E3A218: G_allocate_cell_buf (alloc_cell.c:66)
==30423== by 0x400E7C: patch_density (main.c:74)
==30423== by 0x54B775C: worker (worker.c:190)
==30423== by 0x54B458D: calculateIndex (daemon.c:91)
==30423== by 0x400DC5: main (main.c:53)
==30423==
==30423== LEAK SUMMARY:
==30423== definitely lost: 826,105,960 bytes in 83,495 blocks
==30423== indirectly lost: 0 bytes in 0 blocks
==30423== possibly lost: 39,600 bytes in 4 blocks
==30423== still reachable: 140,446 bytes in 69 blocks
==30423== suppressed: 0 bytes in 0 blocks
}}}

I observe that in these commands memory is allocated:

{{{
[neteler@north r.li]$ grep G_allocate_cell_buf */*
r.li.cwed/cwed.c: buf_sup = G_allocate_cell_buf();
r.li.cwed/cwed.c: buf_corr = G_allocate_cell_buf();
r.li.daemon/main.c.unused: sup = G_allocate_cell_buf();
r.li.daemon/worker.c: cm->cache[used + i] =
G_allocate_cell_buf();
r.li.daemon/worker.c: old = G_allocate_cell_buf();
r.li.edgedensity/edgedensity.c: buf_sup = G_allocate_cell_buf();
r.li.edgedensity/edgedensity.c: buf_inf = G_allocate_cell_buf();
r.li.mps/mps.c: buf_sup = G_allocate_cell_buf();
r.li.mps/mps.c: buf = G_allocate_cell_buf();
r.li.padcv/padcv.c: buf_sup = G_allocate_cell_buf();
r.li.padcv/padcv.c: buf = G_allocate_cell_buf();
r.li.padrange/padrange.c: buf_sup = G_allocate_cell_buf();
r.li.padrange/padrange.c: buf = G_allocate_cell_buf();
r.li.padsd/padsd.c: buf_sup = G_allocate_cell_buf();
r.li.padsd/padsd.c: buf = G_allocate_cell_buf();
r.li.patchdensity/main.c: sup = G_allocate_cell_buf();
r.li.patchnum/main.c: sup = G_allocate_cell_buf();
}}}

but never released:

{{{
[neteler@north r.li]$ grep G_free */* | grep 'buf\|sup' | grep -v mask
[neteler@north r.li]$
}}}

Attached patch seems to cure the problem.
Ok to submit?

Note: I am unsure about adding a G_free(old); in
"raster/r.li/r.li.daemon/worker.c, line 262.

Markus

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1030&gt;
GRASS GIS <http://grass.osgeo.org>

#1030: r.li.* memory leak + patch
----------------------+-----------------------------------------------------
  Reporter: neteler | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: fixed | Keywords:
  Platform: All | Cpu: All
----------------------+-----------------------------------------------------
Changes (by neteler):

  * status: new => closed
  * resolution: => fixed

Comment:

Submitted as r41900 (6.4), r41901 (6.5), r41902 (7).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1030#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>