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

Reply via email to