Opened 10 years ago

Closed 10 years ago

#1030 closed defect (fixed)

r.li.* memory leak + patch

Reported by: neteler Owned by: grass-dev@…
Priority: normal Milestone: 6.4.0
Component: Raster Version: 6.4.0 RCs
Keywords: Cc:
CPU: All Platform: All

Description

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

Attachments (1)

r.li_free.diff (3.7 KB) - added by neteler 10 years ago.
patches to fix memory leaks

Download all attachments as: .zip

Change History (2)

Changed 10 years ago by neteler

Attachment: r.li_free.diff added

patches to fix memory leaks

comment:1 Changed 10 years ago by neteler

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.