You are not logged in.
Hi,
When using TSQLRequest.Step or directly sqlite3_step() and in case of SQLITE_CONSTRAINT error result over prepared statement FastMM detects memory leaks on shutdown.
The leaks are always constant in size, does not depend on sqlite3 step iterations.
Table: CREATE TABLE Key(ID INTEGER PRIMARY KEY AUTOINCREMENT, CreateTime INTEGER, ModTime INTEGER, Hash INTEGER, Name TEXT COLLATE SYSTEMNOCASE)
Index: CREATE UNIQUE INDEX IndexKeyHash ON Key(Hash)
Prepared statement: 'INSERT INTO Key VALUES (NULL, @1, @2, @3, @4)'
The leak happens if I try to violate IndexKeyHash
sqlite3_finalize(stmt) is called, and it seems I am doing nothing wrong, as far as I can see.
Is someone aware of this problem, or can reproduce it?
Thanks.
Offline
Got it.
define:
fKeySelectRequest: TSQLRequest;
on create:
fKeySelectRequest.Prepare(fClient.DB.DB, 'SELECT ID FROM TABLE WHERE COL=@1');
on destroy:
fKeySelectRequest.Close
is leaking if no step iteration called.
Offline
It may be an issue in the way the SQLite3 engine is called.
If I understand you well, the issue is with a Prepare + Close without Step in-between?
If sqlite3_finalize(stmt), it should not leak memory, at least from the official SQLite3 documentation point of view.
The mORMot way of using SQLite3 statements sounds quite standard.
So I do not know what is wrong here.
Could you find out where the leaked memory block is allocated within SQLite3?
Offline
Hi ab,
It is very easy reproducable:
sqlite3_prepare_v2(fClient.DB.DB, testsql, -1, fTestStmt, fTestTail)
sqlite3_reset(fTestStmt); //With or without, same leaks
sqlite3_finalize(fTestStmt);
StackTrace is:
4046FA [System][@GetMem]
558200 [SynSQLite3.pas][SynSQLite3][@Synsqlite3_malloc][2446]
55D783 [SynSQLite3]
55DF07 [SynSQLite3][@Synsqlite3_sqlite3_memory_highwater]
564167 [SynSQLite3][@Synsqlite3_sqlite3_realloc]
...
Can you reproduce it?
PS: Excuse me. All the problems seems that the Client (fClient.DB.DB) is disposed before the sqlite3_finalize.
Fixed.
Very sorry for bothering you.
Last edited by chapa (2012-05-09 14:07:56)
Offline