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

GRASS GIS trac at osgeo.org
Thu Apr 8 05:58:24 EDT 2010


#1030: r.li.* memory leak + patch
---------------------+------------------------------------------------------
 Reporter:  neteler  |       Owner:  grass-dev at 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 at 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 at north r.li]$ grep G_free */* | grep 'buf\|sup' | grep -v mask
 [neteler at 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>
GRASS GIS <http://grass.osgeo.org>


More information about the grass-dev mailing list