[GRASS5] v.in.ascii updates

[Hamish]

> It's funny, sqpFreeStmt(st) was realy missing in execute(), I thought 
> that I had checked it already before. 50000 points - dbf: 100MB ->
> 10MB

cool. 

I can now import the 1.1 million point sample LIDAR data set 
(lidaratm2.txt.gz, 31.5mb uncompressed) from-
  http://mpa.itc.it/grasstutor/data_menu2nd.phtml

According to top, v.in.ascii using that file drives the dbf process up
to 248mb now and during "Registering lines" part the v.in.ascii process
goes up to 435mb memory use -- still a few small leaks? re-run valgrind?

(I don't understand why a point-only vector file is worrying about
lines?)


> Thank you Hamish. Should I fix that also in the 6.0 branch?

seems like a perfect candidate for 6.0.1 to me.


H

> 
> Finally Helena can use 6.
> 
> Radim
> 
> 
> Hamish wrote:
> >>>>>I finally got around to installing valgrind to check where the
> >>>>>memory leaks are.
> >>>
> >>>..
> >>>
> >>>
> >>>>Can you do the same for the driver?
> > 
> > ..
> > 
> >>The module creates the driver as a new process (fork-exec). I think
> >>that  you have to use --trace-children=yes.
> > 
> > 
> > ok,
> > 
> > CMD="v.in.ascii in=test_pts.dat out=test4 --o"
> > valgrind -v --tool=addrcheck --leak-check=yes --trace-children=yes
> > $CMD
> > 
> > 
> > Memcheck log: 
> >  http://bambi.otago.ac.nz/hamish/grass/memleak/v.in.ascii/memchk_child.txt
> > 
> > 
> > Look for process 2030 (dbf):
> > 
> > ==2230== 36748400 bytes in 48100 blocks are definitely lost in loss
> > record 15 of 16 ==2230==    at 0x3414CFE5: calloc
> > (vg_replace_malloc.c:176) ==2230==    by 0x3416AAB9: sqpInitStmt
> > (alloc.c:30) ==2230==    by 0x804B09F: execute (dbfexe.c:58)
> > ==2230==    by 0x804D5CA: db__driver_execute_immediate
> > (execute.c:29)
> > 
> > 
> > 
> > Also graphical Massif test, heap growth analysis: (end of page)
> >   http://bambi.otago.ac.nz/hamish/grass/memleak/v.in.ascii/
> > 
> > 
> > 
> > Hamish