You're corrupting the stack somewhere.
You can enable stack checking if you're using gcc. -fstack-protector -fstack-protector-all Might help identify where it's actually happening. Michael D. Black Senior Scientist Advanced Analytics Directorate Advanced GEOINT Solutions Operating Unit Northrop Grumman Information Systems ________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of ChingChang Hsiao [chingchang.hs...@overturenetworks.com] Sent: Wednesday, November 02, 2011 10:36 AM To: sqlite-users@sqlite.org Subject: EXT :[sqlite] core dump happened in sqlite3_step for 30 statements in BEGIN TRANSACTION executing every 10 Millisecond Take 3 I can't reply in my system, so I create the problem description again. It seems it's not the problem of sprintf. If it comes from sprintf array size, the core dump will be like this " in __stack_chk_fail () from /lib/libc.so.6". The code dump happened after 4 days' run in a test script, not immediately. The SQLITE statements seem to be ok. Could be a performance issue? ChingChang The source code is shown as below, char tempString[1024]; vector<string> dbStatements; dbStatements.push_back( "BEGIN TRANSACTION;" ); for ( int x = 0; x < 10; x++ ) { sprintf( tempString, "update utilization_table set utilization=%5.2f,sample=%d where slot='0' and device='cavium' and resource='bus' and sample='%d';", ntohd(msg->bus_util[x]), x, x ); dbStatements.push_back( tempString ); sprintf( tempString, "update utilization_table set utilization=%5.2f,sample=%d where slot='0' and device='cavium' and resource='icache' and sample='%d';", 100.00-ntohd(msg->inst_hit_rate[x]), // Convert to misses x, x ); dbStatements.push_back( tempString ); sprintf( tempString, "update utilization_table set utilization=%5.2f,sample=%d where slot='0' and device='cavium' and resource='dcache' and sample='%d';", 100.00-ntohd(msg->data_hit_rate[x]), // Convert to misses x, x ); dbStatements.push_back( tempString ); } dbStatements.push_back( "COMMIT;" ); // populate the DB vector<string>::iterator dbStatementsIter; SqlQuery oper_db(operDatabase, __FILE__, __LINE__); for ( dbStatementsIter = dbStatements.begin(); dbStatementsIter != dbStatements.end(); dbStatementsIter++ ) { oper_db.execw( *(dbStatementsIter) ); } dbStatements.clear(); The core dump is shown as below. #0 0x32e94b04 in raise () from /lib/libc.so.6 #1 0x32e962f4 in abort () from /lib/libc.so.6 #2 0x32e8c2a4 in __assert_fail () from /lib/libc.so.6 #3 0x32ae60cc in ?? () from /ovn/lib/libsqlite3.mgmt-crd.so #4 0x32b4c324 in ?? () from /ovn/lib/libsqlite3.mgmt-crd.so #5 0x32ba12c0 in ?? () from /ovn/lib/libsqlite3.mgmt-crd.so #6 0x32b7926c in sqlite3_step () from /ovn/lib/libsqlite3.mgmt-crd.so #7 0x32b7a2c4 in sqlite3_exec () from /ovn/lib/libsqlite3.mgmt-crd.so #8 0x329a9630 in SqlQuery::execw () from /ovn/lib/libPlatform.so #9 0x329a98e8 in SqlQuery::execw () from /ovn/lib/libPlatform.so #10 0x10010290 in NpuMessageHandler::processUtilReport (this=<value optimized out>, msg=<value optimized out>, nbytes=<value optimized out>) at cavium_driver.cpp:1387 #11 0x10012808 in NpuMessageHandler::run (this=0x38be1008) at cavium_driver.cpp:954 #12 0x328a65b0 in Thread::start_thread () from /ovn/lib/libCommon.mgmt-crd.so #13 0x3278b5cc in ?? () from /lib/libpthread.so.0 #14 0x32f39b88 in clone () from /lib/libc.so.6 _______________________________________________ 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users