Doug Nebeker wrote:
It sounds to me that he isn't saying it is leaking--it simply isn't
releasing memory after a SELECT statement finishes (is finalized). This
might be by design. I would expect the data to be released if the
database connection is closed, but not necessarily after each SELECT.
It would be nice to have an API to force any cached pages to be released
(maybe it already exists and I don't know about it?).
-----Original Message-----
From: Robert Simpson [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 16, 2006 12:13 PM
To: [email protected]
Subject: Re: [sqlite] RE:Re: [sqlite] RE: SQLite memory leak on Windows
CE
----- Original Message -----
From: <[EMAIL PROTECTED]>
I have run your program on the CE emulator (Pocket PC 2003) and i got
the same memory leak.
I have inserted 2 buttons on a MFC dialog application.
The first button executes your code and the second button closes the
application.
If you examine the memory you will discover that the program only free
the memory once you exit from the apllication, meanwhile it reserves
memory as its needed (on demand, but see details below).
the memory behaviour of SQLite is quite strange, an example:
lets say that a select sentence reserves 1000kb of memory, once this
local process has finished memory keeps reserved for the program (it
should be freed), if another process executes a select sentence that
needs 200kb SQLite will not reserve 200k more, it will use 200k of the
previous 1000k reserved. if a 3rd process executes a select sentence
that needs 1300k SQlite will reserve 300kb more and those 1300kb will
not be freed until the main dialog application closes (even if the 3
process where local methods or functions).
Ok this is where you lost me. 3 processes? Is your program running 3
times on the CE platform? If CE is running 3 instances of your program,
then they definitely won't be sharing any memory and yes you'll
definitely run out.
Also if I recall correctly, CE 5.0 will not let you run multiple
instances of the same program.
If you're talking about 3 SELECT statements in the same program using
the same connection instance, then that's another story.
The problem is that if a select sentence consume most of the memory it
will not be freed and the program will execute very slow until you
exit from the application because there will be so little memory left
for other not SQLite process that the program might be unusable.
SQLite's default cache size is about 3mb. After opening a connection,
try executing "PRAGMA cache_size=8" or some really low number and tell
me if its still "leaking".
Robert
To find out more about Reuters visit www.about.reuters.com
Any views expressed in this message are those of the individual sender, except
where the sender specifically states them to be the views of Reuters Ltd.
He uses the table API call to get the output. By necessity this must
allocate dynamic memory to accommodate the result set. We can guess
that he then runs through the table and looks at the result rows.
If he were to use an sqlite3_step and process each row as it is
retrieved that dynamic memory requirement would be eliminated. Not only
would memory usage be better controlled, but the application would run
faster by eliminating the delay while te table is created.
Some thought on how malloc and free work would help in conceptualising
the application. The best that can usually be achieved is that over a
period of time the application hits a memory "high water mark" and does
not go beyond that. Minimizing dynamic memory allocation limits that
high water level. Free cannot be guaranteed to ensure that malloc'd
memory is totally reused. That requires garbage collection.
