[GRASS-windows] Anisotropic buffer for polygons?

Tue Jun 9 23:49:14 EDT 2009

Following-up on this one the v.buffer command also works for me with  
anisotropic polygon buffers when running GRASS 6.4.0RC4 on Ubuntu 8.04.

Thanks for the help, and looks like it is a Windows specific bug.

Apologies too if this doesn't land in the right place in the thread, I'm  
not sure how to respond to these things properly with g-mail.

Brian.

On Jun 8, 2009 4:36pm, Markus Neteler <neteler at osgeo.org> wrote:
> (cc grass-dev for inspection)

> On Mon, Jun 8, 2009 at 10:35 PM, Brian Krzyscokrzys 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 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-windows/attachments/20090610/912cc9dc/attachment.html