[sqlite] Reuse of TCL array causes memory leak

2006-04-21 Thread Aldobino Braga
I've run into an issue where the reuse of a TCL array (to hold query
results) causes a catastrophic memory leak. The eval command is called
with the same array name again and again.  Each successive query / array
population exponentially consumes more and more memory (until the system
crashes).

Since eval is responsible for the array creation, it seems to me that it
should be responsible for calling array unset before it populates the
data.  When I call array unset myself, everything works as expected. 

Perhaps this is the expected behavior, however I was unable to find anything
in the documentation regarding it.
Would anyone care to comment?

Regards,
Al Braga




Re: [sqlite] Reuse of TCL array causes memory leak

2006-04-21 Thread drh
Aldobino Braga [EMAIL PROTECTED] wrote:
 I've run into an issue where the reuse of a TCL array (to hold query
 results) causes a catastrophic memory leak. The eval command is called
 with the same array name again and again.  Each successive query / array
 population exponentially consumes more and more memory (until the system
 crashes).
 
 Since eval is responsible for the array creation, it seems to me that it
 should be responsible for calling array unset before it populates the
 data.  When I call array unset myself, everything works as expected. 
 
 Perhaps this is the expected behavior, however I was unable to find anything
 in the documentation regarding it.
 Would anyone care to comment?
 

A common idiom is to do this:

db eval {SELECT * FROM table} v break

After this statement runs, the array variable v contains
the content of the first row of the table.  Sometimes you
see two or three SELECT statements in a row populating the
same array:

db eval {SELECT * FROM table1} v break
db eval {SELECT * FROM table2} v break
...
db eval {SELECT * FROM tableN} v break

All of the about (which is commonly used) would break if
SQLite tried to do unsets for you.

I think, therefore, that the current behavior is correct.
--
D. Richard Hipp   [EMAIL PROTECTED]