On 2014/06/14 02:00, Sohail Somani wrote:
I think I'm pretty certain that my program *is* the culprit. I'd like to add the tracing to SQLite itself. Which functions do you
suggest? I know you mentioned opening/closing so that would be sqlite3_open* and sqlite3_finalize?
Just to clarify, this is all happening within one process:
Write thread: write
Read thread: read something
Write thread: write
Write thread: write
Read thread: read something <-- this is a "special" query but I can't see
anything special about it except that it uses FTS
Write thread: hang until app exits
Also, I tried using sqlite3_config to add logging but that didn't seem to do
much. Time for some printfs...
Hi again Sohail,
The things for which you should log with any returned object/memory pointers
are:
(Jotting this down from memory as I am not at my desk, so spellings might be
off, but you'd know the things I refer to)
sqlite3_openXX() // because I have in the past accidentally opened a connection twice, which is perfectly ok in sqlite terms, but
may not be the intention of your code.
sqlite3_close() // To match to the opens.
sqlite3_prepareXX() // whichever you are using
sqlite3_reset()
sqlite3_unprepare() // Yes I forgot the name for this, _finalize maybe?
Whatever kills/frees the prepared statement.
sqlite3_execute() // In case you bypass the whole prepare-step-free business
by using some direct SQL
Also please log in terms of the TCL or sending any SQL statements like BEGIN or SAVEPOINT or any of their aliases and other
transaction-flow/ending functions.
That should supply you with a large enough view to trap any out-of-place or
non-closed/non-finalized stuff.
Anyone else reading this with an experience like the OP's that was solved,
kindly add to this list, or any other thoughts that may help.
Cheers!
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
