[GRASS-dev] v.net.visibility memory leak? - was Re: [GRASS-user] traveling salesman problem in air

[Markus Metz]

Markus Neteler wrote:
> ...
> And again the new valgrind output:
>
> ...
> ==17614== 1,200 bytes in 3 blocks are indirectly lost in loss record 4 of 16
> ==17614==    at 0x4C1F144: calloc (vg_replace_malloc.c:397)
> ==17614==    by 0x5D3F976: dig__alloc_space (allocation.c:81)
> ==17614==    by 0x5D4D415: dig_alloc_points (struct_alloc.c:248)
> ==17614==    by 0x4E5B200: Vect__Read_line_nat (read_nat.c:309)
> ==17614==    by 0x4E5AC11: V1_read_next_line_nat (read_nat.c:82)
> ==17614==    by 0x4E5A8EE: Vect_read_next_line (read.c:76)
> ==17614==    by 0x4E3CB00: Vect_build_nat (build_nat.c:522)
> ==17614==    by 0x4E3AD22: Vect_build_partial (build.c:134)
> ==17614==    by 0x4E3AC15: Vect_build (build.c:55)
> ==17614==    by 0x40320C: main (main.c:132)
>   
I remember a discussion in the dev ml, I think with the osgeo4w 
installer, that memory allocated with malloc/calloc/realloc should be 
free-d with free, not G_free. If this is the case, then there is a 
problem in the vector libs, because space for a struct line_pnts * is 
allocated with calloc and free-d with G_free, and relevant (or all) 
calls to malloc/calloc/realloc/free in diglib should be replaced with 
G_malloc etc. What to do?
> ==17614==
> ==17614==
> ==17614== 449,106 bytes in 56 blocks are still reachable in loss record 10 of 16
> ==17614==    at 0x4C2136E: malloc (vg_replace_malloc.c:207)
> ==17614==    by 0x529603E: G__malloc (alloc.c:41)
> ==17614==    by 0x52CE929: G_store (store.c:36)
> ==17614==    by 0x52C29D9: G_set_program_name (progrm_nme.c:52)
> ==17614==    by 0x52AEAD2: G__gisinit (gisinit.c:51)
> ==17614==    by 0x402D97: main (main.c:42)
>   
Need for a complement to G_gisinit that free-s that memory?
> ==17614==
> ==17614== LEAK SUMMARY:
> ==17614==    definitely lost: 7,604 bytes in 42 blocks.
> ==17614==    indirectly lost: 1,200 bytes in 3 blocks.
> ==17614==      possibly lost: 0 bytes in 0 blocks.
> ==17614==    still reachable: 73,854,014 bytes in 414,618 blocks.
> ==17614==         suppressed: 0 bytes in 0 blocks.
>
>
> not much changed...
>   
If Vect_set_release_support() does not cause a severe time penalty, I 
would recommend to use it. IMHO 73,854,014 - 444,026 (previous result) 
bytes = ca. 70 MB lingering around in memory is a bit unnecessary.

Markus M