[sqlite] BEGIN DEFERRED TRANSACTION causes core dump in a heavily periodic load with BEGIN EXCLUSIVE/IMMEDIATE TRANSACTION in version 3.7.5
I believe it is a bug in 3.7.5. It didn't happen in 3.6.22. It causes core dump when using BEGIN DEFERRED TRANSACTION in one of our application to access DB periodically(every 1 second) . There are other applications access the same DB periodically but using BEGIN EXCLUSIVE/IMMEDIATE TRANSACTION. Only the application with BEGIN DEFERRED TRANSACTION went to core dump. It seems that it doesn't get the lock for some reasons and fails in assert. After changing from BEGIN DEFERRED TRANSACTION to BEGIN EXCLUSIVE TRANSACTION in this application, the problem is gone. The core dump report is shown as below. ChingChang (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
Re: [sqlite] BEGIN DEFERRED TRANSACTION causes core dump in a heavily periodic load with BEGIN EXCLUSIVE/IMMEDIATE TRANSACTION in version 3.7.5
On Tue, Apr 5, 2011 at 2:39 PM, ChingChang Hsiao chingchang.hs...@overturenetworks.com wrote: I believe it is a bug in 3.7.5. It didn't happen in 3.6.22. It causes core dump when using BEGIN DEFERRED TRANSACTION in one of our application to access DB periodically(every 1 second) . There are other applications access the same DB periodically but using BEGIN EXCLUSIVE/IMMEDIATE TRANSACTION. Only the application with BEGIN DEFERRED TRANSACTION went to core dump. It seems that it doesn't get the lock for some reasons and fails in assert. After changing from BEGIN DEFERRED TRANSACTION to BEGIN EXCLUSIVE TRANSACTION in this application, the problem is gone. The core dump report is shown as below. ChingChang Please recompile using -O0 instead of -O3. Rerun your test and send us the resulting stack trace, and we will investigate further. (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 -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] BEGIN DEFERRED TRANSACTION causes core dump in a heavily periodic load with BEGIN EXCLUSIVE/IMMEDIATE TRANSACTION in version 3.7.5
On 04/06/2011 01:39 AM, ChingChang Hsiao wrote: I believe it is a bug in 3.7.5. It didn't happen in 3.6.22. It causes core dump when using BEGIN DEFERRED TRANSACTION in one of our application to access DB periodically(every 1 second) . There are other applications access the same DB periodically but using BEGIN EXCLUSIVE/IMMEDIATE TRANSACTION. Only the application with BEGIN DEFERRED TRANSACTION went to core dump. It seems that it doesn't get the lock for some reasons and fails in assert. After changing from BEGIN DEFERRED TRANSACTION to BEGIN EXCLUSIVE TRANSACTION in this application, the problem is gone. The core dump report is shown as below. ChingChang In frame 3, what do you get for p *pBt? And p *pBt-db? Dan. (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
