No, the deadlock is deeper than that, it's stuck trying to lock mutexes. My current theory is that the thread trying to update the page in the backup destination database is what's causing trouble.
I also forgot to mention, each thread is using a different connection object and that it's using shared cache mode. Jon On Aug 25, 2012, at 12:57 PM, Patrik Nilsson wrote: > Do you test for the backup errors, i.e. SQLITE_BUSY and SQLITE_LOCKED? > > Do you test for step errors, i.e. SQLITE_BUSY? > > If you get the busy error, you can wait a while and try again or start over. > > /Patrik > > On 08/24/2012 05:46 PM, Jonathan Engle wrote: >> Ran into this recently, it's happened on one machine running a beta test of >> our software. This is a multi-threaded application, and I've run into a >> sequence of steps that deadlocks hard that as far as I can tell from the >> documentation shouldn't. >> This is using SQLite 3.7.13 with SEE. >> The source database is using WAL mode, all transactions are done as >> IMMEDIATE, synchronous mode is set to 0, and it is encrypted. >> The destination database for the backup is not encrypted, and is default >> (non-WAL, full synchronous) modes. >> >> >> There are multiple threads active: >> >> - one performing a write >> - two performing reads >> - one closing a connection >> - one is in the middle of a backup operation >> >> Here are the call stacks for the threads: >> >> >> Writing thread: >> >> sqlite3_step >> sqlite3VdbeExec >> sqlite3VdbeHalt >> sqlite3BtreeCommitPhaseOne >> sqlite3PagerCommitPhaseOne >> pagerWalFrames >> sqlite3BackupUpdate >> backupOnePage >> sqlite3BtreeEnter >> lockBtreeMutex >> pthread_mutex_lock >> __psynch_mutexwait >> >> Closing a connection thread: >> >> sqlite3_close >> sqlite3BtreeEnterAll >> sqlite3BtreeEnter >> lockBtreeMutex >> pthread_mutex_lock >> __psynch_mutexwait >> >> Reading thread: >> >> sqlite3_step >> sqlite3VdbeExec >> sqlite3VdbeEnter >> sqlite3BtreeEnter >> lockBtreeMutex >> pthread_mutex_lock >> __psynch_mutexwait >> >> Backing up thread: >> >> sqlite3_backup_step >> sqlite3BtreeEnter >> lockBtreeMutex >> pthread_mutex_lock >> __psynch_mutexwait >> >> Reading thread: >> >> sqlite3_step >> sqlite3VdbeExec >> sqlite3VdbeEnter >> sqlite3BtreeEnter >> lockBtreeMutex >> pthread_mutex_lock >> __psynch_mutexwait >> >> >> >> Also, the destination database for the backup is created on the stack by the >> the thread doing the backup and is never passed out to anybody (explicitly). >> >> What looks like is happening to me is that the writing and backing-up thread >> are deadlocking with each other, with 'sqlite3BackupUpdate' attempting to >> update the backup destination database. Unfortunately, this is not >> something I've reproduced locally, so I can't look parameters or lock >> states. I'm going to try, as a kind of hail-mary, putting a BEGIN IMMEDIATE >> transactions around the backup to block writing during the database backup. >> >> If anyone has any suggestions or ideas about what I might be doing wrong >> here, I'd appreciate it. >> >> >> _______________________________________________ >> sqlite-users mailing list >> [email protected] >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
