Markus,
Comments below per usual.
On Thu, 2006-07-06 at 10:12 +0200, Markus Neteler wrote:
Hi,
while testing:
v.random random n=1000000
v.out.ascii random > random.csv
v.in.ascii random.csv out=random2
with the sqlite driver, I observed that it eats a lot
of memory. Since v.in.ascii works ok with the dbf driver, the
problem must be in the sqlite driver. Therein I found some memory
allocations but no G_free():
cd db/drivers/sqlite/
grep malloc *
cursor.c: c = (cursor *) db_malloc(sizeof(cursor));
describe.c: c->kcols = (int *) G_malloc ( nkcols * sizeof(int) );
error.c: errMsg = (dbString *) G_malloc(sizeof(dbString));
My malloc knowledge is limited, do we need to add some
G_free() statements there?
There is nothing inherently wrong with cursor.c and describe.c.
In cursor.c a 'cursor' struct is initially allocated in function
alloc_cursor(). In describe.c, an element of the 'cursor' structure is
allocated. There is also a related function, free_cursor() that free()s
the memory. There is only a memory leak if alloc_cursor() is called
without a corresponding free_cursor(), but the memory is free()d
regardless at executable termination.
I don't see any reason why the memory allocation in describe.c shouldn't
be moved to alloc_cursor() in cursor.c. It may be more readable that
way.
In, error.c a function init_error() allocates enough memory to hold
strings. It appears that the code 'if (!errMsg) {...' functions as a
poor "this only happens once" block. There should probably be a
corresponding free_error() function, but it isn't really necessary since
most people would most likely call it close to program termination.
Sorry for the length, but in short, there's really nothing wrong. 
--
Brad Douglas <rez touchofmadness com> KB8UYR
Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785