Markus Neteler wrote:
On Thu, Apr 16, 2009 at 11:02 AM, Markus Metz
<[email protected]> 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
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
