[GRASS-user] v.delaunay Bug in Mac OS X
Hamish
hamish_b at yahoo.com
Wed Jun 17 05:03:29 EDT 2009
works ok in Linux + latest grass 6.5svn, both 32 and 64bit.
but Valgrind does find an error:
G65> CMD="v.delaunay input=DelaunayPoints output=DelaunayTriangles"
G65> valgrind --tool=memcheck --leak-check=yes --show-reachable=yes $CMD --o
==7844== Memcheck, a memory error detector.
==7844== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==7844== Using LibVEX rev 1854, a library for dynamic binary translation.
==7844== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==7844== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework.
==7844== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==7844== For more details, rerun with: -v
==7844==
WARNING: Vector map <DelaunayTriangles> already exists and will be
overwritten
==7844== Syscall param write(buf) points to uninitialised byte(s)
==7844== at 0x71C09F0: write (in /lib/libc-2.7.so)
==7844== by 0x716E909: _IO_file_write (in /lib/libc-2.7.so)
==7844== by 0x716E569: (within /lib/libc-2.7.so)
==7844== by 0x716E8A4: _IO_do_write (in /lib/libc-2.7.so)
==7844== by 0x7170256: _IO_switch_to_get_mode (in /lib/libc-2.7.so)
==7844== by 0x716ED8F: _IO_file_seekoff (in /lib/libc-2.7.so)
==7844== by 0x7164049: ftell (in /lib/libc-2.7.so)
==7844== by 0x5D455FD: dig_ftell (file.c:41)
==7844== by 0x5D4600F: dig__write_head (head.c:56)
==7844== by 0x4E5AC9C: V1_open_new_nat (open_nat.c:127)
==7844== by 0x4E5A155: Vect_open_new (open.c:565)
==7844== by 0x403B0D: main (main.c:106)
==7844== Address 0x4022009 is not stack'd, malloc'd or (recently) free'd
Building topology for vector map <DelaunayTriangles>...
Registering primitives...
15 primitives registered
30 vertices registered
Building areas...
100%
8 areas built
1 isles built
Number of nodes: 8
Number of primitives: 15
Number of points: 0
Number of lines: 0
Number of boundaries: 15
Number of centroids: 0
Number of areas: 8
Number of isles: 1
Number of areas without centroid: 8
100%
Building topology for vector map <DelaunayTriangles>...
Attaching islands...
100%
Attaching centroids...
100%
Number of nodes: 16
Number of primitives: 23
Number of points: 0
Number of lines: 0
Number of boundaries: 15
Number of centroids: 8
Number of areas: 8
Number of isles: 1
==7844==
==7844== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 20 from 2)
==7844== malloc/free: in use at exit: 140,294 bytes in 304 blocks.
==7844== malloc/free: 541 allocs, 237 frees, 236,013 bytes allocated.
==7844== For counts of detected errors, rerun with: -v
==7844== searching for pointers to 304 not-freed blocks.
==7844== checked 2,836,336 bytes.
==7844==
==7844==
==7844== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 13
==7844== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844== by 0x71DD52F: (within /lib/libc-2.7.so)
==7844== by 0x71DDD06: __nss_database_lookup (in /lib/libc-2.7.so)
==7844== by 0xF1F031F: ???
==7844== by 0xF1F102C: ???
==7844== by 0x719C101: getpwuid_r (in /lib/libc-2.7.so)
==7844== by 0x719B9CE: getpwuid (in /lib/libc-2.7.so)
==7844== by 0x52D6537: G_whoami (whoami.c:70)
==7844== by 0x4E4CCF5: Vect__init_head (init_head.c:44)
==7844== by 0x4E592BE: Vect__open_old (open.c:145)
==7844== by 0x4E59D8E: Vect_open_old (open.c:415)
==7844== by 0x403AAB: main (main.c:96)
==7844==
==7844==
==7844== 80 bytes in 5 blocks are indirectly lost in loss record 2 of 13
==7844== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844== by 0x71DD119: __nss_lookup_function (in /lib/libc-2.7.so)
==7844== by 0xF1F033A: ???
==7844== by 0xF1F102C: ???
==7844== by 0x719C101: getpwuid_r (in /lib/libc-2.7.so)
==7844== by 0x719B9CE: getpwuid (in /lib/libc-2.7.so)
==7844== by 0x52D6537: G_whoami (whoami.c:70)
==7844== by 0x4E4CCF5: Vect__init_head (init_head.c:44)
==7844== by 0x4E592BE: Vect__open_old (open.c:145)
==7844== by 0x4E59D8E: Vect_open_old (open.c:415)
==7844== by 0x403AAB: main (main.c:96)
==7844==
==7844==
==7844== 160 bytes in 5 blocks are indirectly lost in loss record 3 of 13
==7844== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844== by 0x71CCEC3: tsearch (in /lib/libc-2.7.so)
==7844== by 0x71DD0B9: __nss_lookup_function (in /lib/libc-2.7.so)
==7844== by 0xF1F033A: ???
==7844== by 0xF1F102C: ???
==7844== by 0x719C101: getpwuid_r (in /lib/libc-2.7.so)
==7844== by 0x719B9CE: getpwuid (in /lib/libc-2.7.so)
==7844== by 0x52D6537: G_whoami (whoami.c:70)
==7844== by 0x4E4CCF5: Vect__init_head (init_head.c:44)
==7844== by 0x4E592BE: Vect__open_old (open.c:145)
==7844== by 0x4E59D8E: Vect_open_old (open.c:415)
==7844== by 0x403AAB: main (main.c:96)
==7844==
==7844==
==7844== 320 bytes in 10 blocks are still reachable in loss record 4 of 13
==7844== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844== by 0x4E523DB: Vect__new_line_struct (line.c:69)
==7844== by 0x4E523A0: Vect_new_line_struct (line.c:59)
==7844== by 0x403A48: main (main.c:88)
==7844==
==7844==
==7844== 352 bytes in 18 blocks are still reachable in loss record 5 of 13
==7844== at 0x4C22741: realloc (vg_replace_malloc.c:429)
==7844== by 0x529A65E: G__realloc (alloc.c:111)
==7844== by 0x52A948A: set_env (env.c:156)
==7844== by 0x52A91F6: read_env (env.c:104)
==7844== by 0x52A9AD8: G__getenv (env.c:317)
==7844== by 0x52A9A38: G_getenv (env.c:271)
==7844== by 0x52B7CA1: G_location (location.c:63)
==7844== by 0x52B7CB9: G__location_path (location.c:78)
==7844== by 0x52B7C54: G_location_path (location.c:41)
==7844== by 0x52B3368: G__gisinit (gisinit.c:58)
==7844== by 0x40397F: main (main.c:60)
==7844==
==7844==
==7844== 2,560 (160 direct, 2,400 indirect) bytes in 5 blocks are definitely lost in loss record 6 of 13
==7844== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844== by 0x4E523DB: Vect__new_line_struct (line.c:69)
==7844== by 0x4E523A0: Vect_new_line_struct (line.c:59)
==7844== by 0x4037EF: read_sites (in_out.c:169)
==7844== by 0x403C2F: main (main.c:117)
==7844==
==7844==
==7844== 2,424 bytes in 8 blocks are indirectly lost in loss record 7 of 13
==7844== at 0x4C203E4: calloc (vg_replace_malloc.c:397)
==7844== by 0x529A5E1: G__calloc (alloc.c:74)
==7844== by 0x5D42F22: dig__alloc_space (allocation.c:81)
==7844== by 0x5D507A1: dig_alloc_points (struct_alloc.c:239)
==7844== by 0x4E5DDF4: Vect__Read_line_nat (read_nat.c:309)
==7844== by 0x4E5D915: V2_read_line_nat (read_nat.c:138)
==7844== by 0x4E5D5E4: Vect_read_line (read.c:106)
==7844== by 0x403835: read_sites (in_out.c:178)
==7844== by 0x403C2F: main (main.c:117)
==7844==
==7844==
==7844== 3,005 (2,981 direct, 24 indirect) bytes in 33 blocks are definitely lost in loss record 8 of 13
==7844== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844== by 0x529A572: G__malloc (alloc.c:41)
==7844== by 0x52B7CF4: G__location_path (location.c:80)
==7844== by 0x52B7C54: G_location_path (location.c:41)
==7844== by 0x52B3368: G__gisinit (gisinit.c:58)
==7844== by 0x40397F: main (main.c:60)
==7844==
==7844==
==7844== 4,096 bytes in 8 blocks are definitely lost in loss record 9 of 13
==7844== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844== by 0x5F58765: RTreeNewNode (node.c:49)
==7844== by 0x5F577E4: RTreeNewIndex (index.c:29)
==7844== by 0x5D4E8C6: dig_spidx_init (spindex.c:36)
==7844== by 0x5D47364: dig_init_plus (plus.c:94)
==7844== by 0x4E592CE: Vect__open_old (open.c:146)
==7844== by 0x4E59D8E: Vect_open_old (open.c:415)
==7844== by 0x403AAB: main (main.c:96)
==7844==
==7844==
==7844== 6,465 bytes in 116 blocks are still reachable in loss record 10 of 13
==7844== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844== by 0x529A572: G__malloc (alloc.c:41)
==7844== by 0x52D2181: G_store (store.c:36)
==7844== by 0x52C6837: G_set_program_name (progrm_nme.c:52)
==7844== by 0x52B333E: G__gisinit (gisinit.c:51)
==7844== by 0x40397F: main (main.c:60)
==7844==
==7844==
==7844== 7,168 bytes in 14 blocks are still reachable in loss record 11 of 13
==7844== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844== by 0x5F58765: RTreeNewNode (node.c:49)
==7844== by 0x5F577E4: RTreeNewIndex (index.c:29)
==7844== by 0x5D4E8C6: dig_spidx_init (spindex.c:36)
==7844== by 0x5D47364: dig_init_plus (plus.c:94)
==7844== by 0x5D477A0: dig_load_plus (plus.c:274)
==7844== by 0x4E5A784: Vect_open_topo (open.c:751)
==7844== by 0x4E59702: Vect__open_old (open.c:229)
==7844== by 0x4E59D8E: Vect_open_old (open.c:415)
==7844== by 0x403AAB: main (main.c:96)
==7844==
==7844==
==7844== 15,532 bytes in 29 blocks are still reachable in loss record 12 of 13
==7844== at 0x4C203E4: calloc (vg_replace_malloc.c:397)
==7844== by 0x529A5E1: G__calloc (alloc.c:74)
==7844== by 0x5D42F22: dig__alloc_space (allocation.c:81)
==7844== by 0x5D4CC01: buf_alloc (portable.c:55)
==7844== by 0x5D4CECE: dig__fread_port_L (portable.c:150)
==7844== by 0x5D4BAFD: dig_Rd_Plus_head (plus_struct.c:614)
==7844== by 0x4E5A6B9: Vect_open_topo (open.c:722)
==7844== by 0x4E59702: Vect__open_old (open.c:229)
==7844== by 0x4E59D8E: Vect_open_old (open.c:415)
==7844== by 0x403AAB: main (main.c:96)
==7844==
==7844==
==7844== 100,504 bytes in 52 blocks are still reachable in loss record 13 of 13
==7844== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==7844== by 0x529A64B: G__realloc (alloc.c:109)
==7844== by 0x5D5043B: dig_alloc_nodes (struct_alloc.c:99)
==7844== by 0x5D4781F: dig_load_plus (plus.c:290)
==7844== by 0x4E5A784: Vect_open_topo (open.c:751)
==7844== by 0x4E59702: Vect__open_old (open.c:229)
==7844== by 0x4E59D8E: Vect_open_old (open.c:415)
==7844== by 0x403AAB: main (main.c:96)
==7844==
==7844== LEAK SUMMARY:
==7844== definitely lost: 7,289 bytes in 47 blocks.
==7844== indirectly lost: 2,664 bytes in 18 blocks.
==7844== possibly lost: 0 bytes in 0 blocks.
==7844== still reachable: 130,341 bytes in 239 blocks.
==7844== suppressed: 0 bytes in 0 blocks.
.... and I just fixed a minor commenting bug in in_out.c (which was
already found+fixed in grass 7 but noone ever mentioned to backport
it... mmph)
Hamish
--- On Tue, 6/16/09, Michael Perdue <michael_perdue at yahoo.ca> wrote:
> From: Michael Perdue <michael_perdue at yahoo.ca>
> Subject: [GRASS-user] v.delaunay Bug in Mac OS X
> To: "GRASS user list" <grass-user at lists.osgeo.org>
> Date: Tuesday, June 16, 2009, 10:50 PM
> Hi,
>
> v.delaunay is generating incorrect results on Mac OS X on
> my machine (Intel Mac Pro, Leopard, W. Kyngesburye's GRASS
> 6.4-RC5 binaries). The following commands give the results
> below;
>
> echo "456490.2375|5905949.8625|1
> 456690.09166667|5905895.5625|2
> 456570.93333333|5905821.65416667|3
> 456579.22916667|5905881.9875|4
> 456494.00833333|5905859.3625|5
> 456673.5|5905819.39166667|6
> 456601.85416667|5905782.4375|7
> 456604.11666667|5905944.58333333|8" | v.in.ascii -n
> output=DelaunayPoints cat=3
>
> v.delaunay input=DelaunayPoints output=DelaunayTriangles
> Building topology for vector map
> <DelaunayTriangles>...
> Registering primitives...
> 12 primitives registered
> 24 vertices registered
> Building areas...
> 100%
> 4 areas built
> 1 isles built
> Number of nodes: 8
> Number of primitives: 12
> Number of points: 0
> Number of lines: 0
> Number of boundaries: 12
> Number of centroids: 0
> Number of areas: 4
> Number of isles: 1
> Number of incorrect boundaries: 4
> Number of areas without centroid: 4
> WARNING: Unable to calculate area
> centroid z coordinate
> 100%
> Building topology for vector map
> <DelaunayTriangles>...
> Attaching islands...
> 100%
> Attaching centroids...
> 100%
> Number of nodes: 11
> Number of primitives: 15
> Number of points: 0
> Number of lines: 0
> Number of boundaries: 12
> Number of centroids: 3
> Number of areas: 4
> Number of isles: 1
> Number of incorrect boundaries: 4
> Number of areas without centroid: 1
>
>
> g.region vect=DelaunayPoints
>
> d.mon x0
> d.vect DelaunayTriangles
> d.vect map=DelaunayPoints color=red width=0
> icon=basic/circle size=10
>
>
>
>
> I've tested it on the same machine running Linux and had no
> issue. It also ran without issue on Mac OS X with GRASS 6.3.
> Can anyone verify that it isn't working properly anymore or
> could it be a problem with my installation?
>
> Cheers,
>
> Mike
> -----Inline Attachment Follows-----
>
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
More information about the grass-user
mailing list