Opened 15 years ago
Closed 15 years ago
#1030 closed defect (fixed)
r.li.* memory leak + patch
Reported by: | neteler | Owned by: | |
---|---|---|---|
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)
Change History (2)
by , 15 years ago
Attachment: | r.li_free.diff added |
---|
comment:1 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
patches to fix memory leaks