[GRASS5] 5.7.1

[Markus Neteler]

On Mon, Dec 06, 2004 at 06:58:12PM +0100, Roger Bivand wrote:
> On Mon, 6 Dec 2004, Markus Neteler wrote:
> 
> > Helena,
> > (cc grass5)
> > 
> > On Sun, Dec 05, 2004 at 04:07:22PM -0500, Helena wrote:
> > > Markus,
> > > 
> > > as I said already all we need for now is to prevent the code to go into 
> > > swapping and
> > > freeze the users machines when their file is too big for their memory (this 
> > > seems to
> > > be needed for both v.in.sites and v.in.ascii run without flags). 
> > 
> > I don't think that we can prevent GRASS from swapping as it is
> > done by the operating system (however, better to discuss this in 'grass5' with
> > the other experts).
> > 
> > I tried v.in.sites on
> > http://mpa.itc.it/grasstutor/data_menu2nd.phtml
> > nclidar-utm.tar.gz: Ready to use GRASS LOCATION in UTM (39.5MB) for North Carolina
> > 
> > and it swaps too much for me as well (1GB RAM). There seems to be a memory
> > leak either in v.in.sites or the underlying DBMI engine.
> > 
> > Radim is out of town currently, and I have zero experience to track
> > down memory leaks.
> 
> Recently Professor Brian Ripley applied valgrind to contributed packages 
> in the R project with positive results, valgrind is not invasive, and may 
> point to memory leaks: http://valgrind.kde.org/, a copy of his posting 
> 
> https://stat.ethz.ch/pipermail/r-devel/2004-November/031264.html
> 
> "Valgrind is easy to use. Valgrind uses dynamic binary translation, so you 
> don't need to modify, recompile or relink your applications. Just prefix 
> your command line with valgrind and everything works."
> 
> It sounds a bit as though trying this here might bring rewards?
> 

Roger,

thanks for your suggestion! 'urpmi valgrid' brought it to me (Mdk10.0, V2.1.0) and
I could run it easily (naturally pretty slow):

cat ~/grass57/lidaratm3.txt | valgrind --tool=memcheck --leak-check=yes v.in.ascii \
    -z out=mypoints zcol=3 catcol=0 fs=',' columns='x double, y double, z double'
[...]
==16082== 12 bytes in 1 blocks are definitely lost in loss record 1 of 16
==16082==    at 0x4002ADAB: malloc (vg_replace_malloc.c:160)
==16082==    by 0x4023F599: Vect_new_list (list.c:29)
==16082==    by 0x4023477D: Vect_build_nat (build_nat.c:454)
==16082==    by 0x40233016: Vect_build_partial (build.c:138)
==16082==
==16082==
==16082== 32 bytes in 2 blocks are definitely lost in loss record 3 of 16
==16082==    at 0x4002ADAB: malloc (vg_replace_malloc.c:160)
==16082==    by 0x40235979: Vect__new_cats_struct (cats.c:50)
==16082==    by 0x40235935: Vect_new_cats_struct (cats.c:39)
==16082==    by 0x804B95E: points_to_bin (points.c:186)
==16082==
==16082==
==16082== 60 bytes in 3 blocks are definitely lost in loss record 4 of 16
==16082==    at 0x4002ADAB: malloc (vg_replace_malloc.c:160)
==16082==    by 0x4023E319: Vect__new_line_struct (line.c:50)
==16082==    by 0x4023E2D5: Vect_new_line_struct (line.c:39)
==16082==    by 0x804B953: points_to_bin (points.c:185)
==16082==
==16082==
==16082== 1214 bytes in 22 blocks are definitely lost in loss record 6 of 16
==16082==    at 0x4002ADAB: malloc (vg_replace_malloc.c:160)
==16082==    by 0x40694840: G_malloc (alloc.c:23)
==16082==    by 0x406AE3B4: G__location_path (location.c:83)
==16082==    by 0x406AE2DC: G_location_path (location.c:43)
==16082==
==16082==
==16082== 1904 bytes in 4 blocks are definitely lost in loss record 8 of 16
==16082==    at 0x4002ADAB: malloc (vg_replace_malloc.c:160)
==16082==    by 0x4027CCAD: RTreeNewNode (node.c:47)
==16082==    by 0x4027C3E5: RTreeNewIndex (index.c:27)
==16082==    by 0x4025F8F8: dig_spidx_init (spindex.c:38)
...

The output looks useful (I tried with a small file, will re-run with a large
one to catch the real problem).

Thanks for the hint, hopefully others try as well.

Markus