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

Reply via email to