Anisotropic buffer for polygons?

[Brian Krzys]

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 [hidden email] 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?

 

Thanks, Brian Krzys.

_______________________________________________
grass-windows mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-windows

[Brian Krzys]

OK, seems like attachments are not working out of g-mail or with the list manager, here is the question again without an attachment:

 

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 (in original post).  I am running 6.4.0 on Win XP.
 
v.buffer [hidden email] 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?
 
Thanks, Brian.

_______________________________________________
grass-windows mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-windows

[Markus Neteler]

(cc grass-dev for inspection)

On Mon, Jun 8, 2009 at 10:35 PM, Brian Krzys<[hidden email]> 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@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


_______________________________________________
grass-windows mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-windows

[Brian Krzys]

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 <[hidden email]> wrote:

> (cc grass-dev for inspection)
>
>
>
> On Mon, Jun 8, 2009 at 10:35 PM, Brian [hidden email]> 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@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
>

_______________________________________________
grass-windows mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-windows