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

[Markus Metz]

Markus Neteler wrote:
> On Thu, Apr 16, 2009 at 11:02 AM, Markus Metz
> <markus.metz.giswork at googlemail.com> wrote:
>   
>> I'm missing Vect_destroy_line_struct(sites) and
>> Vect_destroy_cats_struct(cats) in visibility.c, report() and main.c,
>> count(). Maybe that helps.
>>     
>
> added...
>   
Vect_destroy_line_struct(sites) and Vect_destroy_cats_struct(cats) is 
also missing in main.c, load_lines().
>   
>> Further on, it seems that...
>> - Something's wrong with the RTree, I guess with re-inserting nodes.
>> Debugging the RTree is a major nightmare...
>>     
>
> I can imagine :(
>   
Maybe next week...
>   
>> - Memory allocated by buf_alloc() in diglib is never free-d, must be fixed
>> in diglib, in theory easy.
>>     
>
> ok...
>   
As above, maybe next week.
> [btw:
>
> Attaching centroids...
>  100%
> centroids: 1.000000
> areas to cidx: 0.000000                  <<--- should this be G_debug()?
>   
Yes, changed in r36755. AFAICT, that was only present in develbranch_6. 
Sorry for the confusion!
> Here the new valgrind output:
>   
[...]
> ==16713==
> ==16713== 480 bytes in 1 blocks are still reachable in loss record 3
> of 10
> ==16713==    at 0x4C2136E: malloc (vg_replace_malloc.c:207)
> ==16713==    by 0x5296135: G__realloc (alloc.c:109)
> ==16713==    by 0x4E46602: Vect_add_dblink (field.c:226)
> ==16713==    by 0x4E47333: Vect_read_dblinks (field.c:645)
> ==16713==    by 0x4E56D61: Vect__open_old (open.c:344)
> ==16713==    by 0x4E57029: Vect_open_old (open.c:415)
> ==16713==    by 0x402F7F: main (main.c:81)
>   
I guess that should be free-d by the vector libs when closing a vector.
> ==16713==
> ==16713== 3,696 (96 direct, 3,600 indirect) bytes in 3 blocks are
> definitely lost in loss record 5 of 10
> ==16713==    at 0x4C2136E: malloc (vg_replace_malloc.c:207)
> ==16713==    by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
> ==16713==    by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
> ==16713==    by 0x40360E: load_lines (main.c:242)
> ==16713==    by 0x4031B1: main (main.c:119)
>   
Strange. Isn't there now Vect_destroy_line_struct() in load_lines() ?
> ==16713==
> ==16713==
> ==16713== 1,224 bytes in 5 blocks are indirectly lost in loss record 6
> of 10
> ==16713==    at 0x4C1F144: calloc (vg_replace_malloc.c:397)
> ==16713==    by 0x5D3F976: dig__alloc_space (allocation.c:81)
> ==16713==    by 0x5D4D4CD: dig_alloc_cats (struct_alloc.c:279)
> ==16713==    by 0x4E5B07E: Vect__Read_line_nat (read_nat.c:266)
> ==16713==    by 0x4E5AD24: V2_read_line_nat (read_nat.c:138)
> ==16713==    by 0x4E5AE99: V2_read_next_line_nat (read_nat.c:192)
> ==16713==    by 0x4E5A8EE: Vect_read_next_line (read.c:76)
> ==16713==    by 0x4036C0: load_lines (main.c:245)
> ==16713==    by 0x4031B1: main (main.c:119)
>   
Despite Vect_destroy_cats_struct() ?
Problem with dig__alloc_space ? This is some manual version of 
realloc... OTOH, 1,224 bytes is not a lot.
> ==16713==
> ==16713==
> ==16713== 2,400 bytes in 3 blocks are indirectly lost in loss record 7
> of 10
> ==16713==    at 0x4C1F144: calloc (vg_replace_malloc.c:397)
> ==16713==    by 0x5D3FAF5: dig__frealloc (allocation.c:144)
> ==16713==    by 0x5D3F991: dig__alloc_space (allocation.c:83)
> ==16713==    by 0x5D4D3C9: dig_alloc_points (struct_alloc.c:239)
> ==16713==    by 0x4E5B200: Vect__Read_line_nat (read_nat.c:309)
> ==16713==    by 0x4E5AD24: V2_read_line_nat (read_nat.c:138)
> ==16713==    by 0x4E5AE99: V2_read_next_line_nat (read_nat.c:192)
> ==16713==    by 0x4E5A8EE: Vect_read_next_line (read.c:76)
> ==16713==    by 0x4036C0: load_lines (main.c:245)
> ==16713==    by 0x4031B1: main (main.c:119)
>   
Like above for record 6.
> I assume that the Vect_set_release_support() was suggested only for debugging.
>   
Not really, it is cleaning up memory. No idea why this is not done by 
default in the vector libs every time a vector is closed. Somewhere 
there is a comment in the Programmer's manual that it can take a lot of 
time, maybe that's the reason why it is not done by default.

Markus M