[GRASS5] v.in.ascii updates

[Radim Blazek]

Can you do the same for the driver?

Radim

Hamish wrote:
>>>>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