It seems like the discussion has turned into a general programming
discussion unrelated to SQLite3. Does anyone have an idea about this
specific problem that we encountered (see quoted message below)?
It is not clear to me if this is a threading issue, or memory
corruption issue, or if it is a SQLite3 implementation logic issue
(something to do with a deferred moveto). Why should destroying a
prepared statement care about a cursor's deferred moveto?
Bob
On Wed, 15 Feb 2017, Bob Friesenhahn wrote:
It turns out that I have more data on the problem. The error message
reported reads something like:
SQLITE_CORRUPT: database disk image is malformed database corruption at line
70273 of [17efb4209f]
We are using version 3.10.2.
Looking at amalgamation code I see that the error is returned from
handleDeferredMoveto() and is base on a value returned from
sqlite3BtreeMovetoUnpacked():
70259 ** The cursor "p" has a pending seek operation that has not yet been
70260 ** carried out. Seek the cursor now. If an error occurs, return
70261 ** the appropriate error code.
70262 */
70263 static int SQLITE_NOINLINE handleDeferredMoveto(VdbeCursor *p){
70264 int res, rc;
70265 #ifdef SQLITE_TEST
70266 extern int sqlite3_search_count;
70267 #endif
70268 assert( p->deferredMoveto );
70269 assert( p->isTable );
70270 assert( p->eCurType==CURTYPE_BTREE );
70271 rc = sqlite3BtreeMovetoUnpacked(p->uc.pCursor, 0, p->movetoTarget,
0, &res);
70272 if( rc ) return rc;
70273 if( res!=0 ) return SQLITE_CORRUPT_BKPT;
70274 #ifdef SQLITE_TEST
70275 sqlite3_search_count++;
70276 #endif
70277 p->deferredMoveto = 0;
70278 p->cacheStatus = CACHE_STALE;
70279 return SQLITE_OK;
70280 }
Ideas?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
