On 11/13/2014 05:26 AM, Shaun Seckman (Firaxis) wrote:
Greetings all,
I'm running into a situation in where our application is crashing during a call
to sqlite_backup_finish inside of btreeParseCellPtr because some of the
structure is corrupted.
Both the source and destination database are using the same page sizes and I'm
running everything from within a single-thread.
I'd like to get clarification on one possible issue in order to determine
whether this is the culprit or at least rule it out. This destination
connection (which is an in-memory database) has several prepared statements,
some of which are marked as busy (from sqlite3_stmt_busy) due to having step
called but not reset. All of these statements are read-only (simple select
statements).
My question is, is it safe to have these busy statements on the destination
connection while the backup happens (again, this is all single threaded so
nothing happens DURING the backup process)?
It's not safe.
There are few reasons for this internally - the most obvious is that the
backup operation might change the database schema.
The docs seem to omit this, but basically leaving the active statements
around while the backup happens is the same as using the destination
database while the backup is ongoing. See the "Concurrent Usage of
Database Handles" section at the end of this page:
http://www.sqlite.org/c3ref/backup_finish.html
If not, then should sqlite3_backup_init check for this (at least in debug) and
return NULL if any statements are busy?
I think we likely should. In both debug and non-debug builds.
Thanks for reporting this.
Dan.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
