On March 16, 2006 08:49 am, [EMAIL PROTECTED] wrote:
> Hi Again Robert,
> 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). 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.
>
> Any ideas,
Hi again, I think the problem lies with the type of processor being used
and the way that sqlite (or other programs for that matter) are
written. I think your problem is also related to another thread:
"[sqlite] SQLITE_CORRUPT problem in Mac OS X"
The reason I suggest that is because the Mac uses a power PC I believe,
and in your case it uses an ARM processor.
The Intel, x86, and several processors tend to be able to pack bytes,
words, longs, etc, next to each other. The ARM, the power PC, Sun, and
other risc processors tend to align them on boundaries.
So while, it is easy to point at a string and then use a basic increment
function to look up-n-down a string on an x86, it tends to cause
problems with processors that pack things differently. example:
Please realize I did not test this code, so it may not run as typed.
char x[12] = "Hello world\0";
char *ptr;
while (*ptr) {printf("%c",*ptr); ++ptr;};
The code above should work okay on an x86 or other CISC processor, but
may have problems on some RISC processors due to alignment issues,
especially considering the fact the string was defined using [] but it
is getting accessed using a *ptr and being incremented using ++ or --.
With a RISC processor, you need to take alignment into consideration,
and therefore the distance may not necessarily be ++ or --, but some
other distance.
When I looked at src\table.c I noticed that malloc uses a formula like
(sizeof(char*)*stringsize+1) which is why I suggested trying to modify
line 192 using "result -=(char*);" instead of "result--;"
I hope this makes sense, so although I guessed that -=sizeof(char*);
perhaps it should be another value inserted there, but I'm not that
great a programmer to have guessed the correct value;
Going back to table.c you have this:
----------------------
void sqlite3_free_table(char **azResult){
if( azResult ){ <--this is pointing to azResult[1] if you look at
the previous "sqlite3_get_table()" routines.
int i, n;
azResult--; <--I think this is wrong for ARM processor.
and should be a distance of azResult[1] to azResult[0] which I think is
another value than --
if( azResult==0 ) return; <--probably pointing to wrong spot now!
n = (int)azResult[0];
for(i=1; i<n; i++){ if( azResult[i] ) free(azResult[i]); }
(the line above is accessing info correctly for an ARM but can be coded
quicker using *azResult if an x86 type processor was used, but
unfortunately wouldn't work then)
free(azResult);
}
}
----------------------
I hope the above makes sense, so although I though it was
-=sizeof(char*);
It probably has to be another value, hopefully someone else know.
If you figure out the right sizeof(???) value to use, then I think it
could be submitted as a bug-fix for \src\table.c
