ChingChang Hsiao wrote:
> I can't reply in my system, so I create the problem description again.
>
> I miss one source code line "char tempString[1024];"in the last email. 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?
Core dumps are *never* performance issue.
Indeed, it would be /more efficient/ to prepare statements once (and maybe also
cache prepared statements between function invocations), and just bind different
values in loop, and that's "performance issue", but it is unrelated to
coredumps.
> 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';",
Hmm... One thing to consider: some locales uses different decimal point
separator instead of ".". That may cause problems. E.g.
$ cat >t.c << __EOF__
#include <locale.h>
#include <stdio.h>
int main() { setlocale(LC_ALL, ""); return printf("%5.2f\n", 123.456) < 0; }
__EOF__
$ gcc t.c && LC_ALL=ru_RU.UTF-8 ./a.out
123,46
^ of course, SQL parser won't like this.
But that would likely trigger error *every* time, and not after few hours, so
does not fit your error description.
One more potential problem: NAN and infinity.
printf("%5.2f\n", 1.0/0.0); -> " inf"
printf("%5.2f\n", 0.0/0.0); -> " nan"
That would also confuse SQL parser.
If your ntohd function can sometimes return NAN/infinity, that would cause
problems.
Still, does not fit your error description very well (I'd expect sqlite3_exec to
return error, and don't trigger assertion failure).
Both problem would be avoided by switching to "prepare statement once, then bind
values" pattern.
> 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
Note: this is *not* SIGSEGV/SIGBUS, but *assertion failure*; it prints error on
stderr before program termination, it would be useful to look at this message.
And it would be useful to rebuild libsqlite3.mgmt-crd.so with unstripped
debugging symbols.
> #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
