[GRASS-dev] [bug #4769] (grass) memory leak in v.in.ascii

[Request Tracker]

this bug's URL: http://intevation.de/rt/webrt?serial_num=4769
-------------------------------------------------------------------------

Subject: memory leak in v.in.ascii

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: cvs June 10? 2006

Recent changes in v.in.ascii to support LL data introduced a memory leak for projected data sets. Affected file is vector/v.in.ascii/points.c :points_analyse

tokens = G_tokenize (buf, fs);  allocates an array of char*s that point to various points in buf, but these char*s are not freed before the next G_tokenize. On large lidar point sets, the leak causes out of memory errors. 

There was a G_free_tokens(tokens) inside the loop in an older CVS version (1.12), but I don't think this is right either, as G_free_tokens frees both the char* array AND the buffer. I think the correct order of frees to prevent memory leaks is 

Inside loop: call G_free(tokens), not G_free_tokens(tokens). This frees the char* array, but not the underlying buffer, buf

Outside of while loop: call

G_free(buf)
G_free(tmp_token)
G_free(coorbuf)

Do not call G_free_tokens(tokens) outside of the loop if G_free(tokens) is called inside. 

I do not have LL point data to check this. If you need some projected data to test that both cases work, I can provide a few megabyte sample set. Memory usage in this function should not be more than a few KB, and should not depend on the number of points imported

  



-------------------------------------------- Managed by Request Tracker