Since it apperas you're running your commit in a separate thread and are therefore muilti-threaded I do belive you need: SQLITE3_THREADSAFE=2
>From http://www.sqlite.org/compile.html#threadsafe To put it another way, SQLITE_THREADSAFE=1 sets the default threading mode to Serialized. SQLITE_THREADSAFE=2 sets the default threading mode to Multi-threaded. And SQLITE_THREADSAFE=0 sets the threading mode to Single-threaded. Michael D. Black Senior Scientist NG Information Systems Advanced Analytics Directorate ________________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of ChingChang Hsiao [chingchang.hs...@overturenetworks.com] Sent: Wednesday, March 30, 2011 8:29 PM To: sqlite-users@sqlite.org Subject: EXT :[sqlite] mutex assert_fail in btreeInvokeBusyHandler occasionally in a periodic DB update in 3.5.7, It's ok in 3.6.22(-DSQLITE_THREADSAFE=1) Please neglect the previous 2 emails. Sorry for the inconvenience. Version is 3.5.7 journal mode = DELETE SELECT sqlite_source_id(); 2011-01-28 17:03:50 ed759d5a9edb3bba5f48f243df47be29e3fe8cd7 -DSQLITE_THREADSAFE=1 in Makefile static int btreeInvokeBusyHandler(void *pArg){ BtShared *pBt = (BtShared*)pArg; assert( pBt->db ); assert( sqlite3_mutex_held(pBt->db->mutex) ); return sqlite3InvokeBusyHandler(&pBt->db->busyHandler); } There is a periodic(1 second) DB commit update. It will receive signal 6 assertion fail occasionally. Assert_fail is for sqlite3_mutex_held. Is it something to do with the flag SQLITE_THREADSAFE. Is there anyone could have some ideas for the possible assert_fail reason? It never happened in version 3.6.22. The journal mode is DELETE too. What could be the changes in 3.7.5 cause this problem? (gdb) bt #0 0x3370bb04 in raise () from /lib/libc.so.6 #1 0x3370d2f4 in abort () from /lib/libc.so.6 #2 0x337032a4 in __assert_fail () from /lib/libc.so.6 #3 0x100dc940 in btreeInvokeBusyHandler (pArg=0x102b3b50) at sqlite3.c:47153 #4 0x1013f1dc in sqlite3VdbeHalt (p=0x103ae298) at sqlite3.c:38543 #5 0x1018fda8 in sqlite3VdbeExec (p=<value optimized out>) at sqlite3.c:63340 #6 sqlite3Step (p=0x103ae298) at sqlite3.c:59036 #7 0x101987e8 in sqlite3_step (pStmt=0x103ae298) at sqlite3.c:59101 #8 0x1016cb7c in sqlite3_exec (db=0x10856e18, zSql=0x106b3aa4 "COMMIT;", xCallback=0, pArg=0x0, pzErrMsg=0x388a87c0) at sqlite3.c:84523 #9 0x1003f744 in SqlQuery::execw (this=0x388a8844, sql_stmt=0x106b3aa4 "COMMIT;", context=0x101b91b8 "SlotUtilEvent.cpp", linenum=69, warnings=<value optimized out>) at SqlQuery.cpp:281 #10 0x10089db8 in SlotUtilEvent::run (this=0x10a81e94) at SlotUtilEvent.cpp:94 #11 0x10003f40 in HwMonListener::run (this=0x106b28a8) at /mnt/local/cch/bugfix_test_11_01_02232011/isg6000/isg6k/mgmt-crd/linuxapps/hwmon/hwmon.cpp:1993 #12 0x10025c8c in Thread::start_thread (arg=0x106b28a8) at thread.cpp:199 #13 0x334265cc in ?? () from /lib/libpthread.so.0 #14 0x337b0b88 in clone () from /lib/libc.so.6 Backtrace stopped: previous frame inner to this frame (corrupt stack?) _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
