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

[neteler]

(moving to grass-dev)

[Martina - we need to investigate a bit]

On Wed, Apr 15, 2009 at 10:42 PM, Martina Schäfer
<Martina.Schafer@ebc.uu.se> wrote:

Interesting discussion!! I've created the centroids but unfortunately, the
visibility network module repeatedly crashed (I am using GRASS 6.4 on Mac
OS, but tried on Windows XP as well) with the message "out of memory".

I have run valgrind to check for a memory leak (Linux 64 bit box):
Some funky "uninitialised byte(s)" problem appears... (inline also a
debug msg?):

GRASS 6.5.svn (spearfish60): > CMD="v.net.visibility input=roads
output=graph --o"
GRASS 6.5.svn (spearfish60): > valgrind --tool=memcheck
--leak-check=yes --show-reachable=yes $CMD --o
==3496== Memcheck, a memory error detector.
==3496== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==3496== Using LibVEX rev 1854, a library for dynamic binary translation.
==3496== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==3496== Using valgrind-3.3.1, a dynamic binary instrumentation framework.
==3496== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==3496== For more details, rerun with: -v
==3496==
==3496== Syscall param write(buf) points to uninitialised byte(s)
==3496== at 0x7035D70: write (in /lib64/libc-2.8.so)
==3496== by 0x6FD6EE9: _IO_file_write (in /lib64/libc-2.8.so)
==3496== by 0x6FD7DF8: _IO_do_write (in /lib64/libc-2.8.so)
==3496== by 0x6FD89F6: _IO_switch_to_get_mode (in /lib64/libc-2.8.so)
==3496== by 0x6FD736F: _IO_file_seekoff (in /lib64/libc-2.8.so)
==3496== by 0x6FCCDA9: ftell (in /lib64/libc-2.8.so)
==3496== by 0x5D41F4D: dig_ftell (file.c:40)
==3496== by 0x5D42963: dig__write_head (head.c:56)
==3496== by 0x4E57FE4: V1_open_new_nat (open_nat.c:127)
==3496== by 0x4E57434: Vect_open_new (open.c:565)
==3496== by 0x402EAF: main (main.c:85)
==3496== Address 0x4028009 is not stack'd, malloc'd or (recently) free'd
Building topology for vector map <graph>...
Registering primitives...
330643 primitives registered
661286 vertices registered
primitives: 402.000000
Building areas...
100%
0 areas built
0 isles built
areas: 1.000000
Attaching islands...
isles: 0.000000
Attaching centroids...
100%
centroids: 1.000000
areas to cidx: 0.000000 <<--- should this be G_debug()?
Number of nodes: 4491
Number of primitives: 330643
Number of points: 0
Number of lines: 330643
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
==3496==
==3496== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 1)
==3496== malloc/free: in use at exit: 489,152,702 bytes in 2,067,875 blocks.
==3496== malloc/free: 4,047,776 allocs, 1,979,901 frees, 1,604,422,635
bytes allocated.
==3496== For counts of detected errors, rerun with: -v
==3496== searching for pointers to 2,067,875 not-freed blocks.
==3496== checked 73,330,480 bytes.
==3496==
==3496==
==3496== 192 bytes in 8 blocks are possibly lost in loss record 1 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x529603E: G__malloc (alloc.c:41)
==3496== by 0x4E3E213: Vect__new_cats_struct (cats.c:62)
==3496== by 0x4E3E1C4: Vect_new_cats_struct (cats.c:44)
==3496== by 0x404EB4: report (visibility.c:212)
==3496== by 0x404E5B: handle (visibility.c:198)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496==
==3496== 256 bytes in 8 blocks are still reachable in loss record 2 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
==3496== by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
==3496== by 0x404EAB: report (visibility.c:211)
==3496== by 0x404C70: handle (visibility.c:176)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496==
==3496== 480 bytes in 15 blocks are possibly lost in loss record 3 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
==3496== by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
==3496== by 0x404EAB: report (visibility.c:211)
==3496== by 0x404C70: handle (visibility.c:176)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496==
==3496== 480 bytes in 1 blocks are still reachable in loss record 4 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x5296135: G__realloc (alloc.c:109)
==3496== by 0x4E46602: Vect_add_dblink (field.c:226)
==3496== by 0x4E47333: Vect_read_dblinks (field.c:645)
==3496== by 0x4E56D61: Vect__open_old (open.c:344)
==3496== by 0x4E57029: Vect_open_old (open.c:415)
==3496== by 0x402E5F: main (main.c:81)
==3496==
==3496==
==3496== 2,048 bytes in 4 blocks are definitely lost in loss record 5 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x5F545D6: RTreeNewNode (node.c:49)
==3496== by 0x5F5364C: RTreeNewIndex (index.c:29)
==3496== by 0x5D4B522: dig_spidx_init (spindex.c:36)
==3496== by 0x5D43C94: dig_init_plus (plus.c:94)
==3496== by 0x4E564B2: Vect__open_old (open.c:146)
==3496== by 0x4E57029: Vect_open_old (open.c:415)
==3496== by 0x402E5F: main (main.c:81)
==3496==
==3496==
==3496== 4,800 bytes in 6 blocks are indirectly lost in loss record 6 of 21
==3496== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3496== by 0x5D3FAF5: dig__frealloc (allocation.c:144)
==3496== by 0x5D3F991: dig__alloc_space (allocation.c:83)
==3496== by 0x5D4D3C9: dig_alloc_points (struct_alloc.c:239)
==3496== by 0x4E5B200: Vect__Read_line_nat (read_nat.c:309)
==3496== by 0x4E5AD24: V2_read_line_nat (read_nat.c:138)
==3496== by 0x4E5A9E3: Vect_read_line (read.c:106)
==3496== by 0x403403: count (main.c:200)
==3496== by 0x402FE6: main (main.c:108)
==3496==
==3496==
==3496== 33,700 bytes in 85 blocks are still reachable in loss record 7 of 21
==3496== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3496== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==3496== by 0x5D4983D: buf_alloc (portable.c:55)
==3496== by 0x5D49B0E: dig__fread_port_L (portable.c:150)
==3496== by 0x5D4872D: dig_Rd_Plus_head (plus_struct.c:614)
==3496== by 0x4E579D6: Vect_open_topo (open.c:722)
==3496== by 0x4E5693A: Vect__open_old (open.c:229)
==3496== by 0x4E57029: Vect_open_old (open.c:415)
==3496== by 0x402E5F: main (main.c:81)
==3496==
==3496==
==3496== 38,440 bytes in 1,356 blocks are still reachable in loss
record 8 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x4C214F7: realloc (vg_replace_malloc.c:429)
==3496== by 0x5D4D0A8: dig_alloc_nodes (struct_alloc.c:99)
==3496== by 0x5D44166: dig_load_plus (plus.c:290)
==3496== by 0x4E57AC5: Vect_open_topo (open.c:751)
==3496== by 0x4E5693A: Vect__open_old (open.c:229)
==3496== by 0x4E57029: Vect_open_old (open.c:415)
==3496== by 0x402E5F: main (main.c:81)
==3496==
==3496==
==3496== 40,008 bytes in 1 blocks are still reachable in loss record 9 of 21
==3496== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==3496== by 0x5D4D0A8: dig_alloc_nodes (struct_alloc.c:99)
==3496== by 0x5D46D50: dig_add_node (plus_node.c:116)
==3496== by 0x5D461D1: add_line (plus_line.c:55)
==3496== by 0x5D46379: dig_add_line (plus_line.c:114)
==3496== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==3496== by 0x4E3AD22: Vect_build_partial (build.c:134)
==3496== by 0x4E3AC15: Vect_build (build.c:55)
==3496== by 0x40314C: main (main.c:132)
==3496==
==3496==
==3496== 223,200 bytes in 558 blocks are possibly lost in loss record 10 of 21
==3496== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3496== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==3496== by 0x5D4D415: dig_alloc_points (struct_alloc.c:248)
==3496== by 0x4E4F3CA: Vect_copy_xyz_to_pnts (line.c:118)
==3496== by 0x404F16: report (visibility.c:219)
==3496== by 0x404C70: handle (visibility.c:176)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496==
==3496== 248,016 bytes in 5,167 blocks are still reachable in loss
record 11 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x5D4CF59: dig_alloc_node (struct_alloc.c:44)
==3496== by 0x5D46D93: dig_add_node (plus_node.c:123)
==3496== by 0x5D461D1: add_line (plus_line.c:55)
==3496== by 0x5D46379: dig_add_line (plus_line.c:114)
==3496== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==3496== by 0x4E3AD22: Vect_build_partial (build.c:134)
==3496== by 0x4E3AC15: Vect_build (build.c:55)
==3496== by 0x40314C: main (main.c:132)
==3496==
==3496==
==3496== 449,309 bytes in 66 blocks are still reachable in loss record
12 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x529603E: G__malloc (alloc.c:41)
==3496== by 0x52CE929: G_store (store.c:36)
==3496== by 0x52C29D9: G_set_program_name (progrm_nme.c:52)
==3496== by 0x52AEAD2: G__gisinit (gisinit.c:51)
==3496== by 0x402CD7: main (main.c:42)
==3496==
==3496==
==3496== 2,645,144 bytes in 4,491 blocks are still reachable in loss
record 13 of 21
==3496== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==3496== by 0x5D4CFF9: dig_node_alloc_line (struct_alloc.c:72)
==3496== by 0x5D46B28: dig_node_add_line (plus_node.c:56)
==3496== by 0x5D46079: add_line (plus_line.c:44)
==3496== by 0x5D46379: dig_add_line (plus_line.c:114)
==3496== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==3496== by 0x4E3AD22: Vect_build_partial (build.c:134)
==3496== by 0x4E3AC15: Vect_build (build.c:55)
==3496== by 0x40314C: main (main.c:132)
==3496==
==3496==
==3496== 2,645,144 bytes in 4,491 blocks are still reachable in loss
record 14 of 21
==3496== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==3496== by 0x5D4D033: dig_node_alloc_line (struct_alloc.c:77)
==3496== by 0x5D46B28: dig_node_add_line (plus_node.c:56)
==3496== by 0x5D4622F: add_line (plus_line.c:64)
==3496== by 0x5D46379: dig_add_line (plus_line.c:114)
==3496== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==3496== by 0x4E3AD22: Vect_build_partial (build.c:134)
==3496== by 0x4E3AC15: Vect_build (build.c:55)
==3496== by 0x40314C: main (main.c:132)
==3496==
==3496==
==3496== 2,648,008 bytes in 1 blocks are still reachable in loss
record 15 of 21
==3496== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==3496== by 0x5D4D15B: dig_alloc_lines (struct_alloc.c:133)
==3496== by 0x5D46344: dig_add_line (plus_line.c:110)
==3496== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==3496== by 0x4E3AD22: Vect_build_partial (build.c:134)
==3496== by 0x4E3AC15: Vect_build (build.c:55)
==3496== by 0x40314C: main (main.c:132)
==3496==
==3496==
==3496== 4,020,168 bytes in 3 blocks are still reachable in loss
record 16 of 21
==3496== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==3496== by 0x5296148: G__realloc (alloc.c:111)
==3496== by 0x52A4EB2: set_env (env.c:156)
==3496== by 0x52A4C44: read_env (env.c:104)
==3496== by 0x52A54CE: G__getenv (env.c:317)
==3496== by 0x52A5410: G_getenv (env.c:271)
==3496== by 0x52B36A0: G_location (location.c:63)
==3496== by 0x52B36B8: G__location_path (location.c:78)
==3496== by 0x52B3644: G_location_path (location.c:41)
==3496== by 0x52AEB0B: G__gisinit (gisinit.c:57)
==3496== by 0x402CD7: main (main.c:42)
==3496==
==3496==
==3496== 7,937,917 (7,937,869 direct, 48 indirect) bytes in 330,646
blocks are definitely lost in loss record 17 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x529603E: G__malloc (alloc.c:41)
==3496== by 0x4E3E213: Vect__new_cats_struct (cats.c:62)
==3496== by 0x4E3E1C4: Vect_new_cats_struct (cats.c:44)
==3496== by 0x404EB4: report (visibility.c:212)
==3496== by 0x404B61: handle (visibility.c:164)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496==
==3496== 26,517,440 bytes in 331,468 blocks are still reachable in
loss record 18 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x5D4D0F9: dig_alloc_line (struct_alloc.c:114)
==3496== by 0x5D45F40: add_line (plus_line.c:27)
==3496== by 0x5D46379: dig_add_line (plus_line.c:114)
==3496== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==3496== by 0x4E3AD22: Vect_build_partial (build.c:134)
==3496== by 0x4E3AC15: Vect_build (build.c:55)
==3496== by 0x40314C: main (main.c:132)
==3496==
==3496==
==3496== 407,100,768 (10,579,968 direct, 396,520,800 indirect) bytes
in 330,624 blocks are definitely lost in loss record 19 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
==3496== by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
==3496== by 0x404EAB: report (visibility.c:211)
==3496== by 0x404B61: handle (visibility.c:164)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496==
==3496== 34,601,984 bytes in 67,582 blocks are still reachable in loss
record 20 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x5F545D6: RTreeNewNode (node.c:49)
==3496== by 0x5F56AF6: RTreeSplitNode (split_q.c:313)
==3496== by 0x5F54E52: RTreeAddBranch (node.c:201)
==3496== by 0x5F53BA3: RTreeInsertRect2 (index.c:121)
==3496== by 0x5F5398A: RTreeInsertRect2 (index.c:102)
==3496== by 0x5F5398A: RTreeInsertRect2 (index.c:102)
==3496== by 0x5F5398A: RTreeInsertRect2 (index.c:102)
==3496== by 0x5F5398A: RTreeInsertRect2 (index.c:102)
==3496== by 0x5F5398A: RTreeInsertRect2 (index.c:102)
==3496== by 0x5F5398A: RTreeInsertRect2 (index.c:102)
==3496== by 0x5F53D81: RTreeInsertRect1 (index.c:162)
==3496==
==3496==
==3496== 396,516,048 bytes in 991,294 blocks are indirectly lost in
loss record 21 of 21
==3496== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3496== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==3496== by 0x5D4D3C9: dig_alloc_points (struct_alloc.c:239)
==3496== by 0x4E4F3CA: Vect_copy_xyz_to_pnts (line.c:118)
==3496== by 0x404F16: report (visibility.c:219)
==3496== by 0x404C70: handle (visibility.c:176)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496== LEAK SUMMARY:
==3496== definitely lost: 18,519,885 bytes in 661,274 blocks.
==3496== indirectly lost: 396,520,848 bytes in 991,300 blocks.
==3496== possibly lost: 223,872 bytes in 581 blocks.
==3496== still reachable: 73,888,097 bytes in 414,720 blocks.
==3496== suppressed: 0 bytes in 0 blocks.

Looks like some memory leak?
E.g.,
data_structures.c: stack = G_malloc(size * sizeof(struct Point));

but there is no G_free(stack).

In visibility.c I also see two malloc() calls instead of G_malloc().

Markus

[Markus_GRASS]

Markus Neteler wrote:

(moving to grass-dev)

[Martina - we need to investigate a bit]

On Wed, Apr 15, 2009 at 10:42 PM, Martina Schäfer
<Martina.Schafer@ebc.uu.se> wrote:
  

Interesting discussion!! I've created the centroids but unfortunately, the
visibility network module repeatedly crashed (I am using GRASS 6.4 on Mac
OS, but tried on Windows XP as well) with the message "out of memory".
    
I have run valgrind to check for a memory leak (Linux 64 bit box):
Some funky "uninitialised byte(s)" problem appears... (inline also a
debug msg?):
  

Some leaks in the vector libs could disappear if Vect_set_release_support() is called just before closing vectors in v.net.visibility. Maybe the output of valgrind becomes a bit shorter and more readable.

Markus M

GRASS 6.5.svn (spearfish60): > CMD="v.net.visibility input=roads
output=graph --o"
GRASS 6.5.svn (spearfish60): > valgrind --tool=memcheck
--leak-check=yes --show-reachable=yes $CMD --o
==3496== Memcheck, a memory error detector.
==3496== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==3496== Using LibVEX rev 1854, a library for dynamic binary translation.
==3496== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==3496== Using valgrind-3.3.1, a dynamic binary instrumentation framework.
==3496== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==3496== For more details, rerun with: -v
==3496==
==3496== Syscall param write(buf) points to uninitialised byte(s)
==3496== at 0x7035D70: write (in /lib64/libc-2.8.so)
==3496== by 0x6FD6EE9: _IO_file_write (in /lib64/libc-2.8.so)
==3496== by 0x6FD7DF8: _IO_do_write (in /lib64/libc-2.8.so)
==3496== by 0x6FD89F6: _IO_switch_to_get_mode (in /lib64/libc-2.8.so)
==3496== by 0x6FD736F: _IO_file_seekoff (in /lib64/libc-2.8.so)
==3496== by 0x6FCCDA9: ftell (in /lib64/libc-2.8.so)
==3496== by 0x5D41F4D: dig_ftell (file.c:40)
==3496== by 0x5D42963: dig__write_head (head.c:56)
==3496== by 0x4E57FE4: V1_open_new_nat (open_nat.c:127)
==3496== by 0x4E57434: Vect_open_new (open.c:565)
==3496== by 0x402EAF: main (main.c:85)
==3496== Address 0x4028009 is not stack'd, malloc'd or (recently) free'd
Building topology for vector map <graph>...
Registering primitives...
330643 primitives registered
661286 vertices registered
primitives: 402.000000
Building areas...
100%
0 areas built
0 isles built
areas: 1.000000
Attaching islands...
isles: 0.000000
Attaching centroids...
100%
centroids: 1.000000
areas to cidx: 0.000000 <<--- should this be G_debug()?
Number of nodes: 4491
Number of primitives: 330643
Number of points: 0
Number of lines: 330643
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
==3496==
==3496== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 1)
==3496== malloc/free: in use at exit: 489,152,702 bytes in 2,067,875 blocks.
==3496== malloc/free: 4,047,776 allocs, 1,979,901 frees, 1,604,422,635
bytes allocated.
==3496== For counts of detected errors, rerun with: -v
==3496== searching for pointers to 2,067,875 not-freed blocks.
==3496== checked 73,330,480 bytes.
==3496==
==3496== 192 bytes in 8 blocks are possibly lost in loss record 1 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x529603E: G__malloc (alloc.c:41)
==3496== by 0x4E3E213: Vect__new_cats_struct (cats.c:62)
==3496== by 0x4E3E1C4: Vect_new_cats_struct (cats.c:44)
==3496== by 0x404EB4: report (visibility.c:212)
==3496== by 0x404E5B: handle (visibility.c:198)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496== 256 bytes in 8 blocks are still reachable in loss record 2 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
==3496== by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
==3496== by 0x404EAB: report (visibility.c:211)
==3496== by 0x404C70: handle (visibility.c:176)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496== 480 bytes in 15 blocks are possibly lost in loss record 3 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
==3496== by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
==3496== by 0x404EAB: report (visibility.c:211)
==3496== by 0x404C70: handle (visibility.c:176)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496== 480 bytes in 1 blocks are still reachable in loss record 4 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x5296135: G__realloc (alloc.c:109)
==3496== by 0x4E46602: Vect_add_dblink (field.c:226)
==3496== by 0x4E47333: Vect_read_dblinks (field.c:645)
==3496== by 0x4E56D61: Vect__open_old (open.c:344)
==3496== by 0x4E57029: Vect_open_old (open.c:415)
==3496== by 0x402E5F: main (main.c:81)
==3496==
==3496== 2,048 bytes in 4 blocks are definitely lost in loss record 5 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x5F545D6: RTreeNewNode (node.c:49)
==3496== by 0x5F5364C: RTreeNewIndex (index.c:29)
==3496== by 0x5D4B522: dig_spidx_init (spindex.c:36)
==3496== by 0x5D43C94: dig_init_plus (plus.c:94)
==3496== by 0x4E564B2: Vect__open_old (open.c:146)
==3496== by 0x4E57029: Vect_open_old (open.c:415)
==3496== by 0x402E5F: main (main.c:81)
==3496==
==3496== 4,800 bytes in 6 blocks are indirectly lost in loss record 6 of 21
==3496== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3496== by 0x5D3FAF5: dig__frealloc (allocation.c:144)
==3496== by 0x5D3F991: dig__alloc_space (allocation.c:83)
==3496== by 0x5D4D3C9: dig_alloc_points (struct_alloc.c:239)
==3496== by 0x4E5B200: Vect__Read_line_nat (read_nat.c:309)
==3496== by 0x4E5AD24: V2_read_line_nat (read_nat.c:138)
==3496== by 0x4E5A9E3: Vect_read_line (read.c:106)
==3496== by 0x403403: count (main.c:200)
==3496== by 0x402FE6: main (main.c:108)
==3496==
==3496== 33,700 bytes in 85 blocks are still reachable in loss record 7 of 21
==3496== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3496== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==3496== by 0x5D4983D: buf_alloc (portable.c:55)
==3496== by 0x5D49B0E: dig__fread_port_L (portable.c:150)
==3496== by 0x5D4872D: dig_Rd_Plus_head (plus_struct.c:614)
==3496== by 0x4E579D6: Vect_open_topo (open.c:722)
==3496== by 0x4E5693A: Vect__open_old (open.c:229)
==3496== by 0x4E57029: Vect_open_old (open.c:415)
==3496== by 0x402E5F: main (main.c:81)
==3496==
==3496== 38,440 bytes in 1,356 blocks are still reachable in loss
record 8 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x4C214F7: realloc (vg_replace_malloc.c:429)
==3496== by 0x5D4D0A8: dig_alloc_nodes (struct_alloc.c:99)
==3496== by 0x5D44166: dig_load_plus (plus.c:290)
==3496== by 0x4E57AC5: Vect_open_topo (open.c:751)
==3496== by 0x4E5693A: Vect__open_old (open.c:229)
==3496== by 0x4E57029: Vect_open_old (open.c:415)
==3496== by 0x402E5F: main (main.c:81)
==3496==
==3496== 40,008 bytes in 1 blocks are still reachable in loss record 9 of 21
==3496== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==3496== by 0x5D4D0A8: dig_alloc_nodes (struct_alloc.c:99)
==3496== by 0x5D46D50: dig_add_node (plus_node.c:116)
==3496== by 0x5D461D1: add_line (plus_line.c:55)
==3496== by 0x5D46379: dig_add_line (plus_line.c:114)
==3496== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==3496== by 0x4E3AD22: Vect_build_partial (build.c:134)
==3496== by 0x4E3AC15: Vect_build (build.c:55)
==3496== by 0x40314C: main (main.c:132)
==3496==
==3496== 223,200 bytes in 558 blocks are possibly lost in loss record 10 of 21
==3496== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3496== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==3496== by 0x5D4D415: dig_alloc_points (struct_alloc.c:248)
==3496== by 0x4E4F3CA: Vect_copy_xyz_to_pnts (line.c:118)
==3496== by 0x404F16: report (visibility.c:219)
==3496== by 0x404C70: handle (visibility.c:176)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496== 248,016 bytes in 5,167 blocks are still reachable in loss
record 11 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x5D4CF59: dig_alloc_node (struct_alloc.c:44)
==3496== by 0x5D46D93: dig_add_node (plus_node.c:123)
==3496== by 0x5D461D1: add_line (plus_line.c:55)
==3496== by 0x5D46379: dig_add_line (plus_line.c:114)
==3496== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==3496== by 0x4E3AD22: Vect_build_partial (build.c:134)
==3496== by 0x4E3AC15: Vect_build (build.c:55)
==3496== by 0x40314C: main (main.c:132)
==3496==
==3496== 449,309 bytes in 66 blocks are still reachable in loss record
12 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x529603E: G__malloc (alloc.c:41)
==3496== by 0x52CE929: G_store (store.c:36)
==3496== by 0x52C29D9: G_set_program_name (progrm_nme.c:52)
==3496== by 0x52AEAD2: G__gisinit (gisinit.c:51)
==3496== by 0x402CD7: main (main.c:42)
==3496==
==3496== 2,645,144 bytes in 4,491 blocks are still reachable in loss
record 13 of 21
==3496== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==3496== by 0x5D4CFF9: dig_node_alloc_line (struct_alloc.c:72)
==3496== by 0x5D46B28: dig_node_add_line (plus_node.c:56)
==3496== by 0x5D46079: add_line (plus_line.c:44)
==3496== by 0x5D46379: dig_add_line (plus_line.c:114)
==3496== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==3496== by 0x4E3AD22: Vect_build_partial (build.c:134)
==3496== by 0x4E3AC15: Vect_build (build.c:55)
==3496== by 0x40314C: main (main.c:132)
==3496==
==3496== 2,645,144 bytes in 4,491 blocks are still reachable in loss
record 14 of 21
==3496== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==3496== by 0x5D4D033: dig_node_alloc_line (struct_alloc.c:77)
==3496== by 0x5D46B28: dig_node_add_line (plus_node.c:56)
==3496== by 0x5D4622F: add_line (plus_line.c:64)
==3496== by 0x5D46379: dig_add_line (plus_line.c:114)
==3496== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==3496== by 0x4E3AD22: Vect_build_partial (build.c:134)
==3496== by 0x4E3AC15: Vect_build (build.c:55)
==3496== by 0x40314C: main (main.c:132)
==3496==
==3496== 2,648,008 bytes in 1 blocks are still reachable in loss
record 15 of 21
==3496== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==3496== by 0x5D4D15B: dig_alloc_lines (struct_alloc.c:133)
==3496== by 0x5D46344: dig_add_line (plus_line.c:110)
==3496== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==3496== by 0x4E3AD22: Vect_build_partial (build.c:134)
==3496== by 0x4E3AC15: Vect_build (build.c:55)
==3496== by 0x40314C: main (main.c:132)
==3496==
==3496== 4,020,168 bytes in 3 blocks are still reachable in loss
record 16 of 21
==3496== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==3496== by 0x5296148: G__realloc (alloc.c:111)
==3496== by 0x52A4EB2: set_env (env.c:156)
==3496== by 0x52A4C44: read_env (env.c:104)
==3496== by 0x52A54CE: G__getenv (env.c:317)
==3496== by 0x52A5410: G_getenv (env.c:271)
==3496== by 0x52B36A0: G_location (location.c:63)
==3496== by 0x52B36B8: G__location_path (location.c:78)
==3496== by 0x52B3644: G_location_path (location.c:41)
==3496== by 0x52AEB0B: G__gisinit (gisinit.c:57)
==3496== by 0x402CD7: main (main.c:42)
==3496==
==3496== 7,937,917 (7,937,869 direct, 48 indirect) bytes in 330,646
blocks are definitely lost in loss record 17 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x529603E: G__malloc (alloc.c:41)
==3496== by 0x4E3E213: Vect__new_cats_struct (cats.c:62)
==3496== by 0x4E3E1C4: Vect_new_cats_struct (cats.c:44)
==3496== by 0x404EB4: report (visibility.c:212)
==3496== by 0x404B61: handle (visibility.c:164)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496== 26,517,440 bytes in 331,468 blocks are still reachable in
loss record 18 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x5D4D0F9: dig_alloc_line (struct_alloc.c:114)
==3496== by 0x5D45F40: add_line (plus_line.c:27)
==3496== by 0x5D46379: dig_add_line (plus_line.c:114)
==3496== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==3496== by 0x4E3AD22: Vect_build_partial (build.c:134)
==3496== by 0x4E3AC15: Vect_build (build.c:55)
==3496== by 0x40314C: main (main.c:132)
==3496==
==3496== 407,100,768 (10,579,968 direct, 396,520,800 indirect) bytes
in 330,624 blocks are definitely lost in loss record 19 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
==3496== by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
==3496== by 0x404EAB: report (visibility.c:211)
==3496== by 0x404B61: handle (visibility.c:164)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496== 34,601,984 bytes in 67,582 blocks are still reachable in loss
record 20 of 21
==3496== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3496== by 0x5F545D6: RTreeNewNode (node.c:49)
==3496== by 0x5F56AF6: RTreeSplitNode (split_q.c:313)
==3496== by 0x5F54E52: RTreeAddBranch (node.c:201)
==3496== by 0x5F53BA3: RTreeInsertRect2 (index.c:121)
==3496== by 0x5F5398A: RTreeInsertRect2 (index.c:102)
==3496== by 0x5F53D81: RTreeInsertRect1 (index.c:162)
==3496==
==3496== 396,516,048 bytes in 991,294 blocks are indirectly lost in
loss record 21 of 21
==3496== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3496== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==3496== by 0x5D4D3C9: dig_alloc_points (struct_alloc.c:239)
==3496== by 0x4E4F3CA: Vect_copy_xyz_to_pnts (line.c:118)
==3496== by 0x404F16: report (visibility.c:219)
==3496== by 0x404C70: handle (visibility.c:176)
==3496== by 0x4050E7: construct_visibility (visibility.c:278)
==3496== by 0x4030EF: main (main.c:125)
==3496==
==3496== LEAK SUMMARY:
==3496== definitely lost: 18,519,885 bytes in 661,274 blocks.
==3496== indirectly lost: 396,520,848 bytes in 991,300 blocks.
==3496== possibly lost: 223,872 bytes in 581 blocks.
==3496== still reachable: 73,888,097 bytes in 414,720 blocks.
==3496== suppressed: 0 bytes in 0 blocks.

Looks like some memory leak?
E.g.,
data_structures.c: stack = G_malloc(size * sizeof(struct Point));

but there is no G_free(stack).

In visibility.c I also see two malloc() calls instead of G_malloc().

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[neteler]

On Thu, Apr 16, 2009 at 8:28 AM, Markus Metz
<markus.metz.giswork@googlemail.com> wrote:

Markus Neteler wrote:

...

I have run valgrind to check for a memory leak (Linux 64 bit box):
Some funky "uninitialised byte(s)" problem appears... (inline also a
debug msg?):

Some leaks in the vector libs could disappear if Vect_set_release_support()
is called just before closing vectors in v.net.visibility. Maybe the output
of valgrind becomes a bit shorter and more readable.

I have added for input and output Vect_set_release_support().
Now it looks like this:

GRASS 6.5.svn (spearfish60):~ > CMD="v.net.visibility input=roads
output=graph --o"
GRASS 6.5.svn (spearfish60):~ > valgrind --tool=memcheck
--leak-check=yes --show-reachable=yes $CMD --o
==3746== Memcheck, a memory error detector.
==3746== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et
al.
==3746== Using LibVEX rev 1854, a library for dynamic binary
translation.
==3746== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==3746== Using valgrind-3.3.1, a dynamic binary instrumentation
framework.
==3746== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et
al.
==3746== For more details, rerun with: -v
==3746==
WARNING: Vector map <graph> already exists and will be overwritten
==3746== Syscall param write(buf) points to uninitialised byte(s)
==3746== at 0x7035D70: write (in /lib64/libc-2.8.so)
==3746== by 0x6FD6EE9: _IO_file_write (in /lib64/libc-2.8.so)
==3746== by 0x6FD7DF8: _IO_do_write (in /lib64/libc-2.8.so)
==3746== by 0x6FD89F6: _IO_switch_to_get_mode (in
/lib64/libc-2.8.so)
==3746== by 0x6FD736F: _IO_file_seekoff (in /lib64/libc-2.8.so)
==3746== by 0x6FCCDA9: ftell (in /lib64/libc-2.8.so)
==3746== by 0x5D41F4D: dig_ftell (file.c:40)
==3746== by 0x5D42963: dig__write_head (head.c:56)
==3746== by 0x4E57FE4: V1_open_new_nat (open_nat.c:127)
==3746== by 0x4E57434: Vect_open_new (open.c:565)
==3746== by 0x402F0F: main (main.c:85)
==3746== Address 0x4028009 is not stack'd, malloc'd or (recently)
free'd
Building topology for vector map <graph>...
Registering primitives...
330643 primitives registered
661286 vertices registered
primitives: 428.000000
Building areas...
100%
0 areas built
0 isles built
areas: 1.000000
Attaching islands...
isles: 0.000000
Attaching centroids...
100%
centroids: 1.000000
areas to cidx: 0.000000
Number of nodes: 4491
Number of primitives: 330643
Number of points: 0
Number of lines: 330643
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
==3746==
==3746== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from
1)
==3746== malloc/free: in use at exit: 415,745,397 bytes in 1,653,341
blocks.
==3746== malloc/free: 4,047,822 allocs, 2,394,481 frees, 1,604,431,184
bytes allocated.
==3746== For counts of detected errors, rerun with: -v
==3746== searching for pointers to 1,653,341 not-freed blocks.
==3746== checked 2,661,584 bytes.
==3746==
==3746==
==3746== 96 bytes in 3 blocks are still reachable in loss record 1 of
14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
==3746== by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
==3746== by 0x404F23: report (visibility.c:211)
==3746== by 0x404BD9: handle (visibility.c:164)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746==
==3746== 144 bytes in 2 blocks are still reachable in loss record 2 of
14
==3746== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==3746== by 0x5296148: G__realloc (alloc.c:111)
==3746== by 0x52A4EB2: set_env (env.c:156)
==3746== by 0x52A4C44: read_env (env.c:104)
==3746== by 0x52A54CE: G__getenv (env.c:317)
==3746== by 0x52A5410: G_getenv (env.c:271)
==3746== by 0x52B36A0: G_location (location.c:63)
==3746== by 0x52B36B8: G__location_path (location.c:78)
==3746== by 0x52B3644: G_location_path (location.c:41)
==3746== by 0x52AEB0B: G__gisinit (gisinit.c:57)
==3746== by 0x402D37: main (main.c:42)
==3746==
==3746==
==3746== 360 bytes in 15 blocks are possibly lost in loss record 3 of
14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x529603E: G__malloc (alloc.c:41)
==3746== by 0x4E3E213: Vect__new_cats_struct (cats.c:62)
==3746== by 0x4E3E1C4: Vect_new_cats_struct (cats.c:44)
==3746== by 0x404F2C: report (visibility.c:212)
==3746== by 0x404CE8: handle (visibility.c:176)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746==
==3746== 384 bytes in 12 blocks are possibly lost in loss record 4 of
14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
==3746== by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
==3746== by 0x404F23: report (visibility.c:211)
==3746== by 0x404CE8: handle (visibility.c:176)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746==
==3746== 480 bytes in 1 blocks are still reachable in loss record 5 of
14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x5296135: G__realloc (alloc.c:109)
==3746== by 0x4E46602: Vect_add_dblink (field.c:226)
==3746== by 0x4E47333: Vect_read_dblinks (field.c:645)
==3746== by 0x4E56D61: Vect__open_old (open.c:344)
==3746== by 0x4E57029: Vect_open_old (open.c:415)
==3746== by 0x402EBF: main (main.c:81)
==3746==
==3746==
==3746== 4,096 bytes in 8 blocks are still reachable in loss record 6
of 14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x5F545D6: RTreeNewNode (node.c:49)
==3746== by 0x5F5364C: RTreeNewIndex (index.c:29)
==3746== by 0x5D4B65C: dig_spidx_free_areas (spindex.c:82)
==3746== by 0x5D4B6C4: dig_spidx_free (spindex.c:105)
==3746== by 0x4E40BA8: Vect_close (close.c:117)
==3746== by 0x4031DC: main (main.c:136)
==3746==
==3746==
==3746== 4,096 bytes in 8 blocks are definitely lost in loss record 7
of 14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x5F545D6: RTreeNewNode (node.c:49)
==3746== by 0x5F5364C: RTreeNewIndex (index.c:29)
==3746== by 0x5D4B522: dig_spidx_init (spindex.c:36)
==3746== by 0x5D43C94: dig_init_plus (plus.c:94)
==3746== by 0x4E564B2: Vect__open_old (open.c:146)
==3746== by 0x4E57029: Vect_open_old (open.c:415)
==3746== by 0x402EBF: main (main.c:81)
==3746==
==3746==
==3746== 4,800 bytes in 6 blocks are indirectly lost in loss record 8
of 14
==3746== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3746== by 0x5D3FAF5: dig__frealloc (allocation.c:144)
==3746== by 0x5D3F991: dig__alloc_space (allocation.c:83)
==3746== by 0x5D4D3C9: dig_alloc_points (struct_alloc.c:239)
==3746== by 0x4E5B200: Vect__Read_line_nat (read_nat.c:309)
==3746== by 0x4E5AD24: V2_read_line_nat (read_nat.c:138)
==3746== by 0x4E5A9E3: Vect_read_line (read.c:106)
==3746== by 0x40347B: count (main.c:202)
==3746== by 0x403046: main (main.c:108)
==3746==
==3746==
==3746== 21,300 bytes in 54 blocks are still reachable in loss record
9 of 14
==3746== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3746== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==3746== by 0x5D4983D: buf_alloc (portable.c:55)
==3746== by 0x5D49B0E: dig__fread_port_L (portable.c:150)
==3746== by 0x5D4872D: dig_Rd_Plus_head (plus_struct.c:614)
==3746== by 0x4E579D6: Vect_open_topo (open.c:722)
==3746== by 0x4E5693A: Vect__open_old (open.c:229)
==3746== by 0x4E57029: Vect_open_old (open.c:415)
==3746== by 0x402EBF: main (main.c:81)
==3746==
==3746==
==3746== 224,400 bytes in 561 blocks are possibly lost in loss record
10 of 14
==3746== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3746== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==3746== by 0x5D4D3C9: dig_alloc_points (struct_alloc.c:239)
==3746== by 0x4E4F3CA: Vect_copy_xyz_to_pnts (line.c:118)
==3746== by 0x404F8E: report (visibility.c:219)
==3746== by 0x404ED3: handle (visibility.c:198)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746==
==3746== 439,326 bytes in 60 blocks are still reachable in loss record
11 of 14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x529603E: G__malloc (alloc.c:41)
==3746== by 0x52CE929: G_store (store.c:36)
==3746== by 0x52C29D9: G_set_program_name (progrm_nme.c:52)
==3746== by 0x52AEAD2: G__gisinit (gisinit.c:51)
==3746== by 0x402D37: main (main.c:42)
==3746==
==3746==
==3746== 7,938,491 (7,938,443 direct, 48 indirect) bytes in 330,657
blocks are definitely lost in loss record 12 of 14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x529603E: G__malloc (alloc.c:41)
==3746== by 0x4E3E213: Vect__new_cats_struct (cats.c:62)
==3746== by 0x4E3E1C4: Vect_new_cats_struct (cats.c:44)
==3746== by 0x404F2C: report (visibility.c:212)
==3746== by 0x404ED3: handle (visibility.c:198)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746==
==3746== 407,112,224 (10,580,224 direct, 396,532,000 indirect) bytes
in 330,632 blocks are definitely lost in loss record 13 of14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
==3746== by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
==3746== by 0x404F23: report (visibility.c:211)
==3746== by 0x404ED3: handle (visibility.c:198)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746==
==3746== 396,527,248 bytes in 991,322 blocks are indirectly lost in
loss record 14 of 14
==3746== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3746== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==3746== by 0x5D4D3C9: dig_alloc_points (struct_alloc.c:239)
==3746== by 0x4E4F3CA: Vect_copy_xyz_to_pnts (line.c:118)
==3746== by 0x404F8E: report (visibility.c:219)
==3746== by 0x404BD9: handle (visibility.c:164)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746== LEAK SUMMARY:
==3746== definitely lost: 18,522,763 bytes in 661,297 blocks.
==3746== indirectly lost: 396,532,048 bytes in 991,328 blocks.
==3746== possibly lost: 225,144 bytes in 588 blocks.
==3746== still reachable: 465,442 bytes in 128 blocks.
==3746== suppressed: 0 bytes in 0 blocks.

Markus

[Markus_GRASS]

Markus Neteler wrote:

On Thu, Apr 16, 2009 at 8:28 AM, Markus Metz
<markus.metz.giswork@googlemail.com> wrote:
  

Markus Neteler wrote:
    

...
  

I have run valgrind to check for a memory leak (Linux 64 bit box):
Some funky "uninitialised byte(s)" problem appears... (inline also a
debug msg?):

Some leaks in the vector libs could disappear if Vect_set_release_support()
is called just before closing vectors in v.net.visibility. Maybe the output
of valgrind becomes a bit shorter and more readable.
    
I have added for input and output Vect_set_release_support().
  

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.

Further on, it seems that...
- Something's wrong with the RTree, I guess with re-inserting nodes. Debugging the RTree is a major nightmare...
- Memory allocated by buf_alloc() in diglib is never free-d, must be fixed in diglib, in theory easy.

Markus M

Now it looks like this:

GRASS 6.5.svn (spearfish60):~ > CMD="v.net.visibility input=roads
output=graph --o"
GRASS 6.5.svn (spearfish60):~ > valgrind --tool=memcheck
--leak-check=yes --show-reachable=yes $CMD --o
==3746== Memcheck, a memory error detector.
==3746== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et
al.
==3746== Using LibVEX rev 1854, a library for dynamic binary
translation.
==3746== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==3746== Using valgrind-3.3.1, a dynamic binary instrumentation
framework.
==3746== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et
al.
==3746== For more details, rerun with: -v
==3746==
WARNING: Vector map <graph> already exists and will be overwritten
==3746== Syscall param write(buf) points to uninitialised byte(s)
==3746== at 0x7035D70: write (in /lib64/libc-2.8.so)
==3746== by 0x6FD6EE9: _IO_file_write (in /lib64/libc-2.8.so)
==3746== by 0x6FD7DF8: _IO_do_write (in /lib64/libc-2.8.so)
==3746== by 0x6FD89F6: _IO_switch_to_get_mode (in
/lib64/libc-2.8.so)
==3746== by 0x6FD736F: _IO_file_seekoff (in /lib64/libc-2.8.so)
==3746== by 0x6FCCDA9: ftell (in /lib64/libc-2.8.so)
==3746== by 0x5D41F4D: dig_ftell (file.c:40)
==3746== by 0x5D42963: dig__write_head (head.c:56)
==3746== by 0x4E57FE4: V1_open_new_nat (open_nat.c:127)
==3746== by 0x4E57434: Vect_open_new (open.c:565)
==3746== by 0x402F0F: main (main.c:85)
==3746== Address 0x4028009 is not stack'd, malloc'd or (recently)
free'd
Building topology for vector map <graph>...
Registering primitives...
330643 primitives registered
661286 vertices registered
primitives: 428.000000
Building areas...
100%
0 areas built
0 isles built
areas: 1.000000
Attaching islands...
isles: 0.000000
Attaching centroids...
100%
centroids: 1.000000
areas to cidx: 0.000000
Number of nodes: 4491
Number of primitives: 330643
Number of points: 0
Number of lines: 330643
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
==3746==
==3746== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from
1)
==3746== malloc/free: in use at exit: 415,745,397 bytes in 1,653,341
blocks.
==3746== malloc/free: 4,047,822 allocs, 2,394,481 frees, 1,604,431,184
bytes allocated.
==3746== For counts of detected errors, rerun with: -v
==3746== searching for pointers to 1,653,341 not-freed blocks.
==3746== checked 2,661,584 bytes.
==3746==
==3746== 96 bytes in 3 blocks are still reachable in loss record 1 of
14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
==3746== by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
==3746== by 0x404F23: report (visibility.c:211)
==3746== by 0x404BD9: handle (visibility.c:164)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746== 144 bytes in 2 blocks are still reachable in loss record 2 of
14
==3746== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==3746== by 0x5296148: G__realloc (alloc.c:111)
==3746== by 0x52A4EB2: set_env (env.c:156)
==3746== by 0x52A4C44: read_env (env.c:104)
==3746== by 0x52A54CE: G__getenv (env.c:317)
==3746== by 0x52A5410: G_getenv (env.c:271)
==3746== by 0x52B36A0: G_location (location.c:63)
==3746== by 0x52B36B8: G__location_path (location.c:78)
==3746== by 0x52B3644: G_location_path (location.c:41)
==3746== by 0x52AEB0B: G__gisinit (gisinit.c:57)
==3746== by 0x402D37: main (main.c:42)
==3746==
==3746== 360 bytes in 15 blocks are possibly lost in loss record 3 of
14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x529603E: G__malloc (alloc.c:41)
==3746== by 0x4E3E213: Vect__new_cats_struct (cats.c:62)
==3746== by 0x4E3E1C4: Vect_new_cats_struct (cats.c:44)
==3746== by 0x404F2C: report (visibility.c:212)
==3746== by 0x404CE8: handle (visibility.c:176)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746== 384 bytes in 12 blocks are possibly lost in loss record 4 of
14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
==3746== by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
==3746== by 0x404F23: report (visibility.c:211)
==3746== by 0x404CE8: handle (visibility.c:176)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746== 480 bytes in 1 blocks are still reachable in loss record 5 of
14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x5296135: G__realloc (alloc.c:109)
==3746== by 0x4E46602: Vect_add_dblink (field.c:226)
==3746== by 0x4E47333: Vect_read_dblinks (field.c:645)
==3746== by 0x4E56D61: Vect__open_old (open.c:344)
==3746== by 0x4E57029: Vect_open_old (open.c:415)
==3746== by 0x402EBF: main (main.c:81)
==3746==
==3746== 4,096 bytes in 8 blocks are still reachable in loss record 6
of 14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x5F545D6: RTreeNewNode (node.c:49)
==3746== by 0x5F5364C: RTreeNewIndex (index.c:29)
==3746== by 0x5D4B65C: dig_spidx_free_areas (spindex.c:82)
==3746== by 0x5D4B6C4: dig_spidx_free (spindex.c:105)
==3746== by 0x4E40BA8: Vect_close (close.c:117)
==3746== by 0x4031DC: main (main.c:136)
==3746==
==3746== 4,096 bytes in 8 blocks are definitely lost in loss record 7
of 14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x5F545D6: RTreeNewNode (node.c:49)
==3746== by 0x5F5364C: RTreeNewIndex (index.c:29)
==3746== by 0x5D4B522: dig_spidx_init (spindex.c:36)
==3746== by 0x5D43C94: dig_init_plus (plus.c:94)
==3746== by 0x4E564B2: Vect__open_old (open.c:146)
==3746== by 0x4E57029: Vect_open_old (open.c:415)
==3746== by 0x402EBF: main (main.c:81)
==3746==
==3746== 4,800 bytes in 6 blocks are indirectly lost in loss record 8
of 14
==3746== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3746== by 0x5D3FAF5: dig__frealloc (allocation.c:144)
==3746== by 0x5D3F991: dig__alloc_space (allocation.c:83)
==3746== by 0x5D4D3C9: dig_alloc_points (struct_alloc.c:239)
==3746== by 0x4E5B200: Vect__Read_line_nat (read_nat.c:309)
==3746== by 0x4E5AD24: V2_read_line_nat (read_nat.c:138)
==3746== by 0x4E5A9E3: Vect_read_line (read.c:106)
==3746== by 0x40347B: count (main.c:202)
==3746== by 0x403046: main (main.c:108)
==3746==
==3746== 21,300 bytes in 54 blocks are still reachable in loss record
9 of 14
==3746== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3746== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==3746== by 0x5D4983D: buf_alloc (portable.c:55)
==3746== by 0x5D49B0E: dig__fread_port_L (portable.c:150)
==3746== by 0x5D4872D: dig_Rd_Plus_head (plus_struct.c:614)
==3746== by 0x4E579D6: Vect_open_topo (open.c:722)
==3746== by 0x4E5693A: Vect__open_old (open.c:229)
==3746== by 0x4E57029: Vect_open_old (open.c:415)
==3746== by 0x402EBF: main (main.c:81)
==3746==
==3746== 224,400 bytes in 561 blocks are possibly lost in loss record
10 of 14
==3746== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3746== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==3746== by 0x5D4D3C9: dig_alloc_points (struct_alloc.c:239)
==3746== by 0x4E4F3CA: Vect_copy_xyz_to_pnts (line.c:118)
==3746== by 0x404F8E: report (visibility.c:219)
==3746== by 0x404ED3: handle (visibility.c:198)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746== 439,326 bytes in 60 blocks are still reachable in loss record
11 of 14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x529603E: G__malloc (alloc.c:41)
==3746== by 0x52CE929: G_store (store.c:36)
==3746== by 0x52C29D9: G_set_program_name (progrm_nme.c:52)
==3746== by 0x52AEAD2: G__gisinit (gisinit.c:51)
==3746== by 0x402D37: main (main.c:42)
==3746==
==3746== 7,938,491 (7,938,443 direct, 48 indirect) bytes in 330,657
blocks are definitely lost in loss record 12 of 14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x529603E: G__malloc (alloc.c:41)
==3746== by 0x4E3E213: Vect__new_cats_struct (cats.c:62)
==3746== by 0x4E3E1C4: Vect_new_cats_struct (cats.c:44)
==3746== by 0x404F2C: report (visibility.c:212)
==3746== by 0x404ED3: handle (visibility.c:198)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746== 407,112,224 (10,580,224 direct, 396,532,000 indirect) bytes
in 330,632 blocks are definitely lost in loss record 13 of14
==3746== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==3746== by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
==3746== by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
==3746== by 0x404F23: report (visibility.c:211)
==3746== by 0x404ED3: handle (visibility.c:198)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746== 396,527,248 bytes in 991,322 blocks are indirectly lost in
loss record 14 of 14
==3746== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==3746== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==3746== by 0x5D4D3C9: dig_alloc_points (struct_alloc.c:239)
==3746== by 0x4E4F3CA: Vect_copy_xyz_to_pnts (line.c:118)
==3746== by 0x404F8E: report (visibility.c:219)
==3746== by 0x404BD9: handle (visibility.c:164)
==3746== by 0x40515F: construct_visibility (visibility.c:278)
==3746== by 0x40314F: main (main.c:125)
==3746==
==3746== LEAK SUMMARY:
==3746== definitely lost: 18,522,763 bytes in 661,297 blocks.
==3746== indirectly lost: 396,532,048 bytes in 991,328 blocks.
==3746== possibly lost: 225,144 bytes in 588 blocks.
==3746== still reachable: 465,442 bytes in 128 blocks.
==3746== suppressed: 0 bytes in 0 blocks.

Markus

[neteler]

On Thu, Apr 16, 2009 at 11:02 AM, Markus Metz
<markus.metz.giswork@googlemail.com> wrote:

Markus Neteler wrote:

On Thu, Apr 16, 2009 at 8:28 AM, Markus Metz

Markus Neteler wrote:

...

I have run valgrind to check for a memory leak (Linux 64 bit box):
Some funky "uninitialised byte(s)" problem appears... (inline also a
debug msg?):

Some leaks in the vector libs could disappear if
Vect_set_release_support()
is called just before closing vectors in v.net.visibility. Maybe the
output
of valgrind becomes a bit shorter and more readable.

I have added for input and output Vect_set_release_support().

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...

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

- Memory allocated by buf_alloc() in diglib is never free-d, must be fixed
in diglib, in theory easy.

ok...

[btw:

Attaching centroids...
100%
centroids: 1.000000
areas to cidx: 0.000000 <<--- should this be G_debug()?
Number of nodes: 4491
Number of primitives: 330643
]

That's in lib/vector/Vlib/build_nat.c

# ------------------------------

Here the new valgrind output:

==16713==
WARNING: Vector map <graph> already exists and will be overwritten
==16713== Syscall param write(buf) points to uninitialised byte(s)
==16713== at 0x7035D70: write (in /lib64/libc-2.8.so)
==16713== by 0x6FD6EE9: _IO_file_write (in /lib64/libc-2.8.so)
==16713== by 0x6FD7DF8: _IO_do_write (in /lib64/libc-2.8.so)
==16713== by 0x6FD89F6: _IO_switch_to_get_mode (in
/lib64/libc-2.8.so)
==16713== by 0x6FD736F: _IO_file_seekoff (in /lib64/libc-2.8.so)
==16713== by 0x6FCCDA9: ftell (in /lib64/libc-2.8.so)
==16713== by 0x5D41F4D: dig_ftell (file.c:40)
==16713== by 0x5D42963: dig__write_head (head.c:56)
==16713== by 0x4E57FE4: V1_open_new_nat (open_nat.c:127)
==16713== by 0x4E57434: Vect_open_new (open.c:565)
==16713== by 0x402FCF: main (main.c:85)
==16713== Address 0x4028009 is not stack'd, malloc'd or (recently)
free'd
Building topology for vector map <graph>...
Registering primitives...
330643 primitives registered
661286 vertices registered
primitives: 422.000000
Building areas...
100%
0 areas built
0 isles built
areas: 1.000000
Attaching islands...
isles: 0.000000
Attaching centroids...
100%
centroids: 1.000000
areas to cidx: 0.000000
Number of nodes: 4491
Number of primitives: 330643
Number of points: 0
Number of lines: 330643
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
==16713==
==16713== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from
1)
==16713== malloc/free: in use at exit: 455,310 bytes in 119 blocks.
==16713== malloc/free: 4,047,822 allocs, 4,047,703 frees,
1,604,431,177 bytes allocated.
==16713== For counts of detected errors, rerun with: -v
==16713== searching for pointers to 119 not-freed blocks.
==16713== checked 2,415,312 bytes.
==16713==
==16713==
==16713== 100 bytes in 1 blocks are still reachable in loss record 1
of 10
==16713== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==16713== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==16713== by 0x5D4983D: buf_alloc (portable.c:55)
==16713== by 0x5D49B0E: dig__fread_port_L (portable.c:150)
==16713== by 0x5D4872D: dig_Rd_Plus_head (plus_struct.c:614)
==16713== by 0x4E579D6: Vect_open_topo (open.c:722)
==16713== by 0x4E5693A: Vect__open_old (open.c:229)
==16713== by 0x4E57029: Vect_open_old (open.c:415)
==16713== by 0x402F7F: main (main.c:81)
==16713==
==16713==
==16713== 144 bytes in 2 blocks are still reachable in loss record 2
of 10
==16713== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==16713== by 0x5296148: G__realloc (alloc.c:111)
==16713== by 0x52A4EB2: set_env (env.c:156)
==16713== by 0x52A4C44: read_env (env.c:104)
==16713== by 0x52A54CE: G__getenv (env.c:317)
==16713== by 0x52A5410: G_getenv (env.c:271)
==16713== by 0x52B36A0: G_location (location.c:63)
==16713== by 0x52B36B8: G__location_path (location.c:78)
==16713== by 0x52B3644: G_location_path (location.c:41)
==16713== by 0x52AEB0B: G__gisinit (gisinit.c:57)
==16713== by 0x402DF7: main (main.c:42)
==16713==
==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)
==16713==
==16713==
==16713== 3,492 (3,468 direct, 24 indirect) bytes in 33 blocks are
definitely lost in loss record 4 of 10
==16713== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==16713== by 0x529603E: G__malloc (alloc.c:41)
==16713== by 0x52B36F3: G__location_path (location.c:80)
==16713== by 0x52B3644: G_location_path (location.c:41)
==16713== by 0x52AEB0B: G__gisinit (gisinit.c:57)
==16713== by 0x402DF7: main (main.c:42)
==16713==
==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)
==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)
==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)
==16713==
==16713==
==16713== 4,096 bytes in 8 blocks are still reachable in loss record 8
of 10
==16713== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==16713== by 0x5F545D6: RTreeNewNode (node.c:49)
==16713== by 0x5F5364C: RTreeNewIndex (index.c:29)
==16713== by 0x5D4B68D: dig_spidx_free_isles (spindex.c:93)
==16713== by 0x5D4B6CD: dig_spidx_free (spindex.c:106)
==16713== by 0x4E40BA8: Vect_close (close.c:117)
==16713== by 0x403290: main (main.c:135)
==16713==
==16713==
==16713== 4,096 bytes in 8 blocks are definitely lost in loss record 9 of 10
==16713== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==16713== by 0x5F545D6: RTreeNewNode (node.c:49)
==16713== by 0x5F5364C: RTreeNewIndex (index.c:29)
==16713== by 0x5D4B522: dig_spidx_init (spindex.c:36)
==16713== by 0x5D43C94: dig_init_plus (plus.c:94)
==16713== by 0x4E564B2: Vect__open_old (open.c:146)
==16713== by 0x4E57029: Vect_open_old (open.c:415)
==16713== by 0x402F7F: main (main.c:81)
==16713==
==16713==
==16713== 439,206 bytes in 55 blocks are still reachable in loss record 10 of 10
==16713== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==16713== by 0x529603E: G__malloc (alloc.c:41)
==16713== by 0x52CE929: G_store (store.c:36)
==16713== by 0x52C29D9: G_set_program_name (progrm_nme.c:52)
==16713== by 0x52AEAD2: G__gisinit (gisinit.c:51)
==16713== by 0x402DF7: main (main.c:42)
==16713==
==16713== LEAK SUMMARY:
==16713== definitely lost: 7,660 bytes in 44 blocks.
==16713== indirectly lost: 3,624 bytes in 8 blocks.
==16713== possibly lost: 0 bytes in 0 blocks.
==16713== still reachable: 444,026 bytes in 67 blocks.
==16713== suppressed: 0 bytes in 0 blocks.

This looks definitely better!

I assume that the Vect_set_release_support() was suggested only for debugging.
Fixed in 6.4.0svn, 6.5.svn and 7 as r36752, r36753, r36754.

Thanks, MarkusM for spotting the problem.

Markus

[Markus_GRASS]

Markus Neteler wrote:

On Thu, Apr 16, 2009 at 11:02 AM, Markus Metz
<markus.metz.giswork@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== 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== 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

[neteler]

On Thu, Apr 16, 2009 at 2:41 PM, Markus Metz
<markus.metz.giswork@googlemail.com> wrote:

Markus Neteler wrote:

On Thu, Apr 16, 2009 at 11:02 AM, Markus Metz

Vect_destroy_line_struct(sites) and Vect_destroy_cats_struct(cats) is also
missing in main.c, load_lines().

added...

...
And again the new valgrind output:

...
==17614== Syscall param write(buf) points to uninitialised byte(s)
==17614== at 0x7035D70: write (in /lib64/libc-2.8.so)
==17614== by 0x6FD6EE9: _IO_file_write (in /lib64/libc-2.8.so)
==17614== by 0x6FD7DF8: _IO_do_write (in /lib64/libc-2.8.so)
==17614== by 0x6FD89F6: _IO_switch_to_get_mode (in /lib64/libc-2.8.so)
==17614== by 0x6FD736F: _IO_file_seekoff (in /lib64/libc-2.8.so)
==17614== by 0x6FCCDA9: ftell (in /lib64/libc-2.8.so)
==17614== by 0x5D41F4D: dig_ftell (file.c:40)
==17614== by 0x5D42963: dig__write_head (head.c:56)
==17614== by 0x4E57FE4: V1_open_new_nat (open_nat.c:127)
==17614== by 0x4E57434: Vect_open_new (open.c:565)
==17614== by 0x402F6F: main (main.c:85)
==17614== Address 0x4028009 is not stack'd, malloc'd or (recently) free'd
Building topology for vector map <graph>...
Registering primitives...
...
==17614==
==17614== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 1)
==17614== malloc/free: in use at exit: 73,862,818 bytes in 414,663 blocks.
==17614== malloc/free: 4,047,814 allocs, 3,633,151 frees,
1,604,427,109 bytes allocated.
==17614== For counts of detected errors, rerun with: -v
==17614== searching for pointers to 414,663 not-freed blocks.
==17614== checked 73,072,728 bytes.
==17614==
==17614==
==17614== 100 bytes in 1 blocks are still reachable in loss record 1 of 16
==17614== at 0x4C1F144: calloc (vg_replace_malloc.c:397)
==17614== by 0x5D3F976: dig__alloc_space (allocation.c:81)
==17614== by 0x5D4983D: buf_alloc (portable.c:55)
==17614== by 0x5D49B0E: dig__fread_port_L (portable.c:150)
==17614== by 0x5D4872D: dig_Rd_Plus_head (plus_struct.c:614)
==17614== by 0x4E579D6: Vect_open_topo (open.c:722)
==17614== by 0x4E5693A: Vect__open_old (open.c:229)
==17614== by 0x4E57029: Vect_open_old (open.c:415)
==17614== by 0x402F1F: main (main.c:81)
==17614==
==17614==
==17614== 480 bytes in 1 blocks are still reachable in loss record 2 of 16
==17614== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==17614== by 0x5296135: G__realloc (alloc.c:109)
==17614== by 0x4E46602: Vect_add_dblink (field.c:226)
==17614== by 0x4E47333: Vect_read_dblinks (field.c:645)
==17614== by 0x4E56D61: Vect__open_old (open.c:344)
==17614== by 0x4E57029: Vect_open_old (open.c:415)
==17614== by 0x402F1F: main (main.c:81)
==17614==
==17614==
==17614== 1,264 (64 direct, 1,200 indirect) bytes in 2 blocks are
definitely lost in loss record 3 of 16
==17614== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==17614== by 0x4E4F2F2: Vect__new_line_struct (line.c:69)
==17614== by 0x4E4F2A8: Vect_new_line_struct (line.c:59)
==17614== by 0x4E3CA67: Vect_build_nat (build_nat.c:496)
==17614== by 0x4E3AD22: Vect_build_partial (build.c:134)
==17614== by 0x4E3AC15: Vect_build (build.c:55)
==17614== by 0x40320C: main (main.c:132)
==17614==
==17614==
==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)
==17614==
==17614==
==17614== 3,444 bytes in 32 blocks are definitely lost in loss record 5 of 16
==17614== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==17614== by 0x529603E: G__malloc (alloc.c:41)
==17614== by 0x52B36F3: G__location_path (location.c:80)
==17614== by 0x52B3644: G_location_path (location.c:41)
==17614== by 0x52AEB0B: G__gisinit (gisinit.c:57)
==17614== by 0x402D97: main (main.c:42)
==17614==
==17614==
==17614== 4,096 bytes in 8 blocks are definitely lost in loss record 6 of 16
==17614== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==17614== by 0x5F545D6: RTreeNewNode (node.c:49)
==17614== by 0x5F5364C: RTreeNewIndex (index.c:29)
==17614== by 0x5D4B522: dig_spidx_init (spindex.c:36)
==17614== by 0x5D43C94: dig_init_plus (plus.c:94)
==17614== by 0x4E564B2: Vect__open_old (open.c:146)
==17614== by 0x4E57029: Vect_open_old (open.c:415)
==17614== by 0x402F1F: main (main.c:81)
==17614==
==17614==
==17614== 38,440 bytes in 1,356 blocks are still reachable in loss
record 7 of 16
==17614== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==17614== by 0x4C214F7: realloc (vg_replace_malloc.c:429)
==17614== by 0x5D4D0A8: dig_alloc_nodes (struct_alloc.c:99)
==17614== by 0x5D44166: dig_load_plus (plus.c:290)
==17614== by 0x4E57AC5: Vect_open_topo (open.c:751)
==17614== by 0x4E5693A: Vect__open_old (open.c:229)
==17614== by 0x4E57029: Vect_open_old (open.c:415)
==17614== by 0x402F1F: main (main.c:81)
==17614==
==17614==
==17614== 40,008 bytes in 1 blocks are still reachable in loss record 8 of 16
==17614== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==17614== by 0x5D4D0A8: dig_alloc_nodes (struct_alloc.c:99)
==17614== by 0x5D46D50: dig_add_node (plus_node.c:116)
==17614== by 0x5D461D1: add_line (plus_line.c:55)
==17614== by 0x5D46379: dig_add_line (plus_line.c:114)
==17614== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==17614== by 0x4E3AD22: Vect_build_partial (build.c:134)
==17614== by 0x4E3AC15: Vect_build (build.c:55)
==17614== by 0x40320C: main (main.c:132)
==17614==
==17614==
==17614== 248,016 bytes in 5,167 blocks are still reachable in loss
record 9 of 16
==17614== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==17614== by 0x5D4CF59: dig_alloc_node (struct_alloc.c:44)
==17614== by 0x5D46D93: dig_add_node (plus_node.c:123)
==17614== by 0x5D461D1: add_line (plus_line.c:55)
==17614== by 0x5D46379: dig_add_line (plus_line.c:114)
==17614== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==17614== by 0x4E3AD22: Vect_build_partial (build.c:134)
==17614== by 0x4E3AC15: Vect_build (build.c:55)
==17614== by 0x40320C: main (main.c:132)
==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)
==17614==
==17614==
==17614== 2,645,144 bytes in 4,491 blocks are still reachable in loss
record 11 of 16
==17614== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==17614== by 0x5D4CFF9: dig_node_alloc_line (struct_alloc.c:72)
==17614== by 0x5D46B28: dig_node_add_line (plus_node.c:56)
==17614== by 0x5D4622F: add_line (plus_line.c:64)
==17614== by 0x5D46379: dig_add_line (plus_line.c:114)
==17614== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==17614== by 0x4E3AD22: Vect_build_partial (build.c:134)
==17614== by 0x4E3AC15: Vect_build (build.c:55)
==17614== by 0x40320C: main (main.c:132)
==17614==
==17614==
==17614== 2,645,144 bytes in 4,491 blocks are still reachable in loss
record 12 of 16
==17614== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==17614== by 0x5D4D033: dig_node_alloc_line (struct_alloc.c:77)
==17614== by 0x5D46B28: dig_node_add_line (plus_node.c:56)
==17614== by 0x5D4622F: add_line (plus_line.c:64)
==17614== by 0x5D46379: dig_add_line (plus_line.c:114)
==17614== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==17614== by 0x4E3AD22: Vect_build_partial (build.c:134)
==17614== by 0x4E3AC15: Vect_build (build.c:55)
==17614== by 0x40320C: main (main.c:132)
==17614==
==17614==
==17614== 2,648,008 bytes in 1 blocks are still reachable in loss
record 13 of 16
==17614== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==17614== by 0x5D4D15B: dig_alloc_lines (struct_alloc.c:133)
==17614== by 0x5D46344: dig_add_line (plus_line.c:110)
==17614== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==17614== by 0x4E3AD22: Vect_build_partial (build.c:134)
==17614== by 0x4E3AC15: Vect_build (build.c:55)
==17614== by 0x40320C: main (main.c:132)
==17614==
==17614==
==17614== 4,020,144 bytes in 3 blocks are still reachable in loss
record 14 of 16
==17614== at 0x4C214A1: realloc (vg_replace_malloc.c:429)
==17614== by 0x5296148: G__realloc (alloc.c:111)
==17614== by 0x52A4EB2: set_env (env.c:156)
==17614== by 0x52A4C44: read_env (env.c:104)
==17614== by 0x52A54CE: G__getenv (env.c:317)
==17614== by 0x52A5410: G_getenv (env.c:271)
==17614== by 0x52B36A0: G_location (location.c:63)
==17614== by 0x52B36B8: G__location_path (location.c:78)
==17614== by 0x52B3644: G_location_path (location.c:41)
==17614== by 0x52AEB0B: G__gisinit (gisinit.c:57)
==17614== by 0x402D97: main (main.c:42)

comment:
http://trac.osgeo.org/grass/ticket/14

==17614==
==17614==
==17614== 26,517,440 bytes in 331,468 blocks are still reachable in
loss record 15 of 16
==17614== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==17614== by 0x5D4D0F9: dig_alloc_line (struct_alloc.c:114)
==17614== by 0x5D45F40: add_line (plus_line.c:27)
==17614== by 0x5D46379: dig_add_line (plus_line.c:114)
==17614== by 0x4E3CB9B: Vect_build_nat (build_nat.c:538)
==17614== by 0x4E3AD22: Vect_build_partial (build.c:134)
==17614== by 0x4E3AC15: Vect_build (build.c:55)
==17614== by 0x40320C: main (main.c:132)
==17614==
==17614==
==17614== 34,601,984 bytes in 67,582 blocks are still reachable in
loss record 16 of 16
==17614== at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==17614== by 0x5F545D6: RTreeNewNode (node.c:49)
==17614== by 0x5F56AF6: RTreeSplitNode (split_q.c:313)
==17614== by 0x5F54E52: RTreeAddBranch (node.c:201)
==17614== by 0x5F53BA3: RTreeInsertRect2 (index.c:121)
==17614== by 0x5F5398A: RTreeInsertRect2 (index.c:102)
==17614== by 0x5F5398A: RTreeInsertRect2 (index.c:102)
==17614== by 0x5F5398A: RTreeInsertRect2 (index.c:102)
==17614== by 0x5F5398A: RTreeInsertRect2 (index.c:102)
==17614== by 0x5F5398A: RTreeInsertRect2 (index.c:102)
==17614== by 0x5F53D81: RTreeInsertRect1 (index.c:162)
==17614== by 0x5F53C2F: RTreeInsertRect (index.c:141)
==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...

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

[Markus_GRASS]

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== 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

[Glynn_Clements1]

Markus Metz wrote:

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?

GRASS code should always use the G_* versions unless there is a clear
reason not to, e.g. if the pointer will be passed to an external
library which will assume ownership of it.

> ==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?

Nope.

Single-instance allocations don't need to be free()d; they can remain
until the process terminates.

Explicitly freeing memory when termination is imminent is a waste of
resources (e.g. CPU cycles, and I/O bandwidth in the case where free()
causes swapped-out memory to be swapped back in). It's colloquially
referred to as "rearranging the deckchairs on the Titanic".

In OO code, where you need to call destructors upon termination for
other reasons, it's quite common to override free() with a no-op as
soon as you are committed to termination, in order to avoid this
issue.

> ==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.

That should only be done if vectors will be closed signficantly prior
to termination, e.g.:

  for (i = 0; i < nvects; i++) {
    vect = Vect_open_old(...);
    ...
    Vect_close(vect);
  }

Valgrind highlights *potential* issues; it isn't omniscient.

[Nor is it an angry god which must be appeased with a sacrifice of
SSH keys.]

--
Glynn Clements <glynn@gclements.plus.com>

[Markus_GRASS]

Glynn Clements wrote:

Markus Metz wrote:

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?
    
GRASS code should always use the G_* versions unless there is a clear
reason not to, e.g. if the pointer will be passed to an external
library which will assume ownership of it.
  

OK, so lib/vector/diglib needs to be updated. What about dglib and rtree? AFAICT they are written such that the code can be used as external standalone libraries and not a single G_*() version is used, I think.

  Single-instance allocations don't need to be free()d; they can remain
until the process terminates.

Explicitly freeing memory when termination is imminent is a waste of
resources (e.g. CPU cycles, and I/O bandwidth in the case where free()
causes swapped-out memory to be swapped back in). It's colloquially
referred to as "rearranging the deckchairs on the Titanic".
  

Clear enough, thanks for the example!

  

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.
    
That should only be done if vectors will be closed signficantly prior
to termination, e.g.:

  for (i = 0; i < nvects; i++) {
    vect = Vect_open_old(...);
    ...
    Vect_close(vect);
  }
  

Can we add this to the Programmer's manual under GRASS 6 Vector Architecture where Vect_set_release_support() is mentioned or have I missed something?

Markus M

[Glynn_Clements1]

Markus Metz wrote:

>> 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?
>>
>
> GRASS code should always use the G_* versions unless there is a clear
> reason not to, e.g. if the pointer will be passed to an external
> library which will assume ownership of it.

OK, so lib/vector/diglib needs to be updated. What about dglib and
rtree? AFAICT they are written such that the code can be used as
external standalone libraries and not a single G_*() version is used, I
think.

Two choices: either rewrite the libraries to use the G_* versions, or
ensure that their callers use free() for pointers returned from those
libraries (if the callers only use deallocation functions provided by
the libraries, this point is moot).

The choice would be influenced by whether the library is available
elsewhere, and if so the extent to which the GRASS version has been
modified, and whether the library requires the caller to allocate or
free memory.

For an unmodified (or minimally modified) version of an external
library which performs all allocation and deallocation itself, I would
leave it using malloc() and free().

If the library isn't available elsewhere, or has been heavily
modified, or it requires the caller to allocate and/or free memory, I
would modify it to use the G_* versions.

>> 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.
>
> That should only be done if vectors will be closed signficantly prior
> to termination, e.g.:
>
> for (i = 0; i < nvects; i++) {
> vect = Vect_open_old(...);
> ...
> Vect_close(vect);
> }

Can we add this to the Programmer's manual under GRASS 6 Vector
Architecture where Vect_set_release_support() is mentioned or have I
missed something?

That would be a good idea, IMHO.

--
Glynn Clements <glynn@gclements.plus.com>