[GRASS-dev] sqlite driver: G_free() missing?

[Brad Douglas]

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