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(>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=) 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=) 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