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