[GRASS5] v.in.ascii updates

[Hamish]

> > > I'm looking to do some v.in.ascii updates, I thought I'd trawl for
> > > comments first.. most deal with format=point mode.
..
> Please report if the massive input points memory leak is fixed/same/
> worse. (e.g. LIDAR)

Still there...


I finally got around to installing valgrind to check where the memory
leaks are.


quick analysis:

just by watching "top" (hit "M" to sort by memory use) in another term,
the v.in.ascii program seems ok; it's the $GISBASE/driver/db/dbf process
which has the leak in it.


valgrind analysis results:
  http://bambi.otago.ac.nz/hamish/grass/memleak/



The main offenders are:

dig_alloc_node (struct_alloc.c:46)
RTreeNewNode (node.c:47)
dig_alloc_line (struct_alloc.c:112)



Left over allocated memory over 1mb at program end:

==880==
==880== 1951960 bytes in 48799 blocks are still reachable in loss record 32 of 34
==880==    at 0x1B906EDD: malloc (vg_replace_malloc.c:131)
==880==    by 0x1B950DB9: dig_alloc_node (struct_alloc.c:46)
==880==    by 0x1B94B1CE: dig_add_node (plus_node.c:114)
==880==    by 0x1B94A641: dig_add_line (plus_line.c:54)
==880==
==880==
==880== 3513528 bytes in 48799 blocks are still reachable in loss record 33 of 34
==880==    at 0x1B906EDD: malloc (vg_replace_malloc.c:131)
==880==    by 0x1B950F65: dig_alloc_line (struct_alloc.c:112)
==880==    by 0x1B94A556: dig_add_line (plus_line.c:45)
==880==    by 0x1B91A922: Vect_build_nat (build_nat.c:481)
==880==
==880==
==880== 9137296 bytes in 19196 blocks are still reachable in loss record 34 of 34
==880==    at 0x1B906EDD: malloc (vg_replace_malloc.c:131)
==880==    by 0x1B972EBE: RTreeNewNode (node.c:47)
==880==    by 0x1B975076: RTreeSplitNode (split_q.c:326)
==880==    by 0x1B97368A: RTreeAddBranch (node.c:205)
==880==
==880== LEAK SUMMARY:
==880==    definitely lost: 4639 bytes in 54 blocks.
==880==    possibly lost:   0 bytes in 0 blocks.
==880==    still reachable: 15994816 bytes in 214537 blocks.
==880==         suppressed: 200 bytes in 1 blocks.


Note for the first two, number of blocks = number of imported points. 


no clue what needs to be freed to fix these..



Hamish