[GRASS-windows] Anisotropic buffer for polygons?
Markus Neteler
neteler at osgeo.org
Mon Jun 8 18:36:06 EDT 2009
(cc grass-dev for inspection)
On Mon, Jun 8, 2009 at 10:35 PM, Brian Krzys<cokrzys at gmail.com> wrote:
> Hi,
>
> I am trying to use v.buffer to create anisotropic buffers around polygons,
> and it doesn't seem to work. Example command included below, and error
> message attached. I am running 6.4.0 on Win XP.
>
> v.buffer input=AltPolys at MAPSET1 output=t1 distance=500 minordistance=100
> angle=45
>
> The ability to create anisotropic buffers seems like a great recent
> addition, and I am using it quite effectively for points, maybe just isn't
> setup for polygons?
On Linux, this seems to work.
Here a memory test:
valgrind --tool=memcheck --leak-check=yes --show-reachable=yes $CMD --o
==7737== Memcheck, a memory error detector.
==7737== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==7737== Using LibVEX rev 1884, a library for dynamic binary translation.
==7737== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==7737== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==7737== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==7737== For more details, rerun with: -v
==7737==
WARNING: Vector map <t1> already exists and will be overwritten
==7737== Syscall param write(buf) points to uninitialised byte(s)
==7737== at 0x70904F0: write (in /lib64/libc-2.9.so)
==7737== by 0x702F8E9: _IO_file_write (in /lib64/libc-2.9.so)
==7737== by 0x70307F8: _IO_do_write (in /lib64/libc-2.9.so)
==7737== by 0x70313F6: _IO_switch_to_get_mode (in /lib64/libc-2.9.so)
==7737== by 0x702FD6F: _IO_file_seekoff (in /lib64/libc-2.9.so)
==7737== by 0x70255E9: ftell (in /lib64/libc-2.9.so)
==7737== by 0x5D44EB1: dig_ftell (file.c:41)
==7737== by 0x5D458F7: dig__write_head (head.c:56)
==7737== by 0x4E5AE38: V1_open_new_nat (open_nat.c:127)
==7737== by 0x4E5A288: Vect_open_new (open.c:565)
==7737== by 0x402790: main (main.c:303)
==7737== Address 0x4029009 is not stack'd, malloc'd or (recently) free'd
Buffering lines...
...
Number of areas: 1
Number of isles: 1
==7737==
==7737== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 1)
==7737== malloc/free: in use at exit: 996,601 bytes in 2,937 blocks.
==7737== malloc/free: 51,003 allocs, 48,066 frees, 13,321,460 bytes allocated.
==7737== For counts of detected errors, rerun with: -v
==7737== Use --track-origins=yes to see where uninitialised values come from
==7737== searching for pointers to 2,937 not-freed blocks.
==7737== checked 3,522,896 bytes.
==7737==
==7737==
==7737== 896 bytes in 28 blocks are still reachable in loss record 1 of 14
==7737== at 0x4C2362E: malloc (vg_replace_malloc.c:207)
==7737== by 0x4E52146: Vect__new_line_struct (line.c:69)
==7737== by 0x4E520FC: Vect_new_line_struct (line.c:59)
==7737== by 0x4026AF: main (main.c:290)
==7737==
==7737==
==7737== 2,976 bytes in 220 blocks are indirectly lost in loss record 2 of 14
==7737== at 0x4C23761: realloc (vg_replace_malloc.c:429)
==7737== by 0x5299148: G__realloc (alloc.c:111)
==7737== by 0x5D4FFB1: dig_node_alloc_line (struct_alloc.c:72)
==7737== by 0x5D49AC8: dig_node_add_line (plus_node.c:56)
==7737== by 0x5D49019: add_line (plus_line.c:44)
==7737== by 0x5D49319: dig_add_line (plus_line.c:114)
==7737== by 0x4E63331: V2_write_line_nat (write_nat.c:359)
==7737== by 0x4E624E1: Vect_write_line (write.c:143)
==7737== by 0x4E372D8: Vect_break_lines_list (break_lines.c:307)
==7737== by 0x4E362F3: Vect_break_lines (break_lines.c:38)
==7737== by 0x40332F: main (main.c:503)
==7737==
==7737==
==7737== 4,096 bytes in 8 blocks are definitely lost in loss record 3 of 14
==7737== at 0x4C2362E: malloc (vg_replace_malloc.c:207)
==7737== by 0x5F575D6: RTreeNewNode (node.c:49)
==7737== by 0x5F5664C: RTreeNewIndex (index.c:29)
==7737== by 0x5D4E4C2: dig_spidx_init (spindex.c:36)
==7737== by 0x5D46C34: dig_init_plus (plus.c:94)
==7737== by 0x4E59306: Vect__open_old (open.c:146)
==7737== by 0x4E59E7D: Vect_open_old (open.c:415)
==7737== by 0x402746: main (main.c:300)
==7737==
==7737==
==7737== 6,144 bytes in 12 blocks are still reachable in loss record 4 of 14
==7737== at 0x4C2362E: malloc (vg_replace_malloc.c:207)
==7737== by 0x5F575D6: RTreeNewNode (node.c:49)
==7737== by 0x5F5664C: RTreeNewIndex (index.c:29)
==7737== by 0x5D4E4C2: dig_spidx_init (spindex.c:36)
==7737== by 0x5D46C34: dig_init_plus (plus.c:94)
==7737== by 0x5D47078: dig_load_plus (plus.c:274)
==7737== by 0x4E5A919: Vect_open_topo (open.c:751)
==7737== by 0x4E5978E: Vect__open_old (open.c:229)
==7737== by 0x4E59E7D: Vect_open_old (open.c:415)
==7737== by 0x402746: main (main.c:300)
==7737==
==7737==
==7737== 6,312 bytes in 13 blocks are indirectly lost in loss record 5 of 14
==7737== at 0x4C2362E: malloc (vg_replace_malloc.c:207)
==7737== by 0x529903E: G__malloc (alloc.c:41)
==7737== by 0x4E4F3BE: Vect_line_intersection (intersect.c:810)
==7737== by 0x4E36C34: Vect_break_lines_list (break_lines.c:219)
==7737== by 0x4E362F3: Vect_break_lines (break_lines.c:38)
==7737== by 0x40332F: main (main.c:503)
==7737==
==7737==
==7737== 9,744 bytes in 3 blocks are possibly lost in loss record 6 of 14
==7737== at 0x4C2362E: malloc (vg_replace_malloc.c:207)
==7737== by 0x529903E: G__malloc (alloc.c:41)
==7737== by 0x4E4F3BE: Vect_line_intersection (intersect.c:810)
==7737== by 0x4E36C34: Vect_break_lines_list (break_lines.c:219)
==7737== by 0x4E362F3: Vect_break_lines (break_lines.c:38)
==7737== by 0x40332F: main (main.c:503)
==7737==
==7737==
==7737== 9,916 bytes in 109 blocks are indirectly lost in loss record 7 of 14
==7737== at 0x4C2362E: malloc (vg_replace_malloc.c:207)
==7737== by 0x5299135: G__realloc (alloc.c:109)
==7737== by 0x5D505A7: dig_area_alloc_line (struct_alloc.c:310)
==7737== by 0x5D47ADA: dig_add_area (plus_area.c:196)
==7737== by 0x4E3EDA6: Vect_build_line_area (build_nat.c:90)
==7737== by 0x4E3FE92: Vect_build_nat (build_nat.c:599)
==7737== by 0x4E3DCA2: Vect_build_partial (build.c:134)
==7737== by 0x40338E: main (main.c:518)
==7737==
==7737==
==7737== 21,756 bytes in 311 blocks are still reachable in loss record 8 of 14
==7737== at 0x4C2362E: malloc (vg_replace_malloc.c:207)
==7737== by 0x529903E: G__malloc (alloc.c:41)
==7737== by 0x52BBBC5: G_define_option (parser.c:243)
==7737== by 0x52BBD4B: G_define_standard_option (parser.c:319)
==7737== by 0x401EEC: main (main.c:151)
==7737==
==7737==
==7737== 27,952 (352 direct, 27,600 indirect) bytes in 11 blocks are
definitely lost in loss record 9 of 14
==7737== at 0x4C2362E: malloc (vg_replace_malloc.c:207)
==7737== by 0x4E52146: Vect__new_line_struct (line.c:69)
==7737== by 0x4E520FC: Vect_new_line_struct (line.c:59)
==7737== by 0x4E3F9F0: Vect_build_nat (build_nat.c:496)
==7737== by 0x4E3DCA2: Vect_build_partial (build.c:134)
==7737== by 0x40338E: main (main.c:518)
==7737==
==7737==
==7737== 27,648 bytes in 16 blocks are indirectly lost in loss record 10 of 14
==7737== at 0x4C21404: calloc (vg_replace_malloc.c:397)
==7737== by 0x52990BC: G__calloc (alloc.c:74)
==7737== by 0x5D42A59: dig__frealloc (allocation.c:144)
==7737== by 0x5D428DD: dig__alloc_space (allocation.c:83)
==7737== by 0x5D50477: dig_alloc_points (struct_alloc.c:257)
==7737== by 0x4E5E054: Vect__Read_line_nat (read_nat.c:309)
==7737== by 0x4E5DA65: V1_read_next_line_nat (read_nat.c:82)
==7737== by 0x4E5D742: Vect_read_next_line (read.c:76)
==7737== by 0x4E3FA74: Vect_build_nat (build_nat.c:519)
==7737== by 0x4E3DCA2: Vect_build_partial (build.c:134)
==7737== by 0x4E3DB95: Vect_build (build.c:55)
==7737== by 0x401C6B: stop (main.c:41)
==7737==
==7737==
==7737== 47,276 bytes in 36 blocks are still reachable in loss record 11 of 14
==7737== at 0x4C23761: realloc (vg_replace_malloc.c:429)
==7737== by 0x5299148: G__realloc (alloc.c:111)
==7737== by 0x52A7EB2: set_env (env.c:156)
==7737== by 0x52A7C44: read_env (env.c:104)
==7737== by 0x52A84CE: G__getenv (env.c:317)
==7737== by 0x52A8410: G_getenv (env.c:271)
==7737== by 0x52B6684: G_location (location.c:63)
==7737== by 0x52B669C: G__location_path (location.c:78)
==7737== by 0x52B6628: G_location_path (location.c:41)
==7737== by 0x52B1B0B: G__gisinit (gisinit.c:58)
==7737== by 0x402360: main (main.c:232)
==7737==
==7737==
==7737== 172,526 bytes in 207 blocks are still reachable in loss
record 12 of 14
==7737== at 0x4C2362E: malloc (vg_replace_malloc.c:207)
==7737== by 0x5299135: G__realloc (alloc.c:109)
==7737== by 0x5D50078: dig_alloc_nodes (struct_alloc.c:99)
==7737== by 0x5D47106: dig_load_plus (plus.c:290)
==7737== by 0x4E5A919: Vect_open_topo (open.c:751)
==7737== by 0x4E5978E: Vect__open_old (open.c:229)
==7737== by 0x4E59E7D: Vect_open_old (open.c:415)
==7737== by 0x402746: main (main.c:300)
==7737==
==7737==
==7737== 213,996 bytes in 87 blocks are still reachable in loss record 13 of 14
==7737== at 0x4C21404: calloc (vg_replace_malloc.c:397)
==7737== by 0x52990BC: G__calloc (alloc.c:74)
==7737== by 0x52BCEC7: G_parser (parser.c:762)
==7737== by 0x402372: main (main.c:234)
==7737==
==7737==
==7737== 492,215 (472,963 direct, 19,252 indirect) bytes in 1,876
blocks are definitely lost in loss record 14 of 14
==7737== at 0x4C2362E: malloc (vg_replace_malloc.c:207)
==7737== by 0x529903E: G__malloc (alloc.c:41)
==7737== by 0x5D500D5: dig_alloc_line (struct_alloc.c:114)
==7737== by 0x5D48EE0: add_line (plus_line.c:27)
==7737== by 0x5D49319: dig_add_line (plus_line.c:114)
==7737== by 0x4E63331: V2_write_line_nat (write_nat.c:359)
==7737== by 0x4E624E1: Vect_write_line (write.c:143)
==7737== by 0x4E372D8: Vect_break_lines_list (break_lines.c:307)
==7737== by 0x4E362F3: Vect_break_lines (break_lines.c:38)
==7737== by 0x40332F: main (main.c:503)
==7737==
==7737== LEAK SUMMARY:
==7737== definitely lost: 477,411 bytes in 1,895 blocks.
==7737== indirectly lost: 46,852 bytes in 358 blocks.
==7737== possibly lost: 9,744 bytes in 3 blocks.
==7737== still reachable: 462,594 bytes in 681 blocks.
==7737== suppressed: 0 bytes in 0 blocks.
Might be a memory leak?
For example, I don't see in main.c
Vect_destroy_cats_struct(Cats);
Vect_destroy_cats_struct(BCats);
which might be necessary.
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v_buffer_polys_error.jpg
Type: image/jpeg
Size: 43914 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-windows/attachments/20090609/d7a963da/v_buffer_polys_error-0001.jpg
More information about the grass-windows
mailing list