high cpu 99% issue

[tenglong88]

Expected behavior

no high cpu for run for 5 days

Actual behavior

high cpu run for 2 hours

Steps to reproduce the problem

(please make this a SSCCE, if applicable and reasonable)

1. multi thread operate sqlite database using poco
2. operate the sqlite different table by different thread every second

POCO version

poco-1.4.3

Compiler and version

m68k-linux-gnu-g++ cross compiler (gcc-4.3.43)

Operating system and version

linux 2.6.25 on m68k(mcf54450vm240)

Other relevant inofrmation

sqlite-3.11.01

high cpu 99% backtrace by gdb:
#0 0x8055c772 in _gnu_cxx::_atomic_add(int volatile*, int) ()
#1 0x8051be9c in std::locale::locale() ()
#2 0x8053e7d4 in std::basic_ostringstream<char, std::char_traits, std::allocator >::basic_ostringstream(std::_Ios_Openmode) ()
warning: (Internal error: pc 0x803d158d in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x803d158d in read in psymtab, but not in symtab.)
#3 0x803d158e in Poco::Data::StatementImpl::StatementImpl (this=warning: (Internal error: pc 0x803d158d in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x803d1518 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x803d158d in read in psymtab, but not in symtab.)
0x80b0b280, rSession=warning: (Internal error: pc 0x803d158d in read in psymtab, but not in symtab.)
@0x80803de0) at src/StatementImpl.cpp:56
#4 0x802a8e90 in Poco::Data::SQLite::SQLiteStatementImpl::SQLiteStatementImpl (this=0x80b0b280, rSession=@0x80803de0, pDB=0x80804ac0)
at src/SQLiteStatementImpl.cpp:47
#5 0x802a02aa in Poco::Data::SQLite::SessionImpl::createStatementImpl (this=0x80803de0) at src/SessionImpl.cpp:83
#6 0x8008cd86 in Poco::Data::StatementCreator::operator<< <char [48]> (this=0x80803d8c, t=@0x805ede26)
at ../common/poco/Data/include/Poco/Data/StatementCreator.h:62
#7 0x8008ce92 in Poco::Data::Session::operator<< <char [48]> (this=0x80803d88, t=@0x805ede26)
at ../common/poco/Data/include/Poco/Data/Session.h:193
#8 0x800bdda4 in ConfigDB::RowCountSQL (this=0x807fe668, tableID=29, panelid=1) at database/obj/../ConfigDB.cpp:3279
#9 0x800be68a in ConfigDB::GetTableInfo (this=0x807fe668, TableID=29, pConfigInfo=0xbcfff54a) at database/obj/../ConfigDB.cpp:3550
#10 0x80039896 in handleGatewayRecord (record=0xbcfff89f "��\226�c\237") at util/obj/../accessdb.c:243
#11 0x8003a038 in handleBonjourRecord (record=0xbcfff89f "��\226�c\237", flag=1) at util/obj/../accessdb.c:177
#12 0x8007a3a0 in taskMdnsProcess (data=0x0) at mDNSClient/obj/../mDNSClient.c:896
#13 0x8046938a in pthread_start_thread (arg=0xbcfffbe0) at manager.c:310
#14 0x805b6b32 in clone ()

[aleks-f]

1. multi thread operate sqlite database using poco
2. operate the sqlite different table by different thread every second

please make this a SSCCE

[tenglong88]

hi, aleks-f:

When in continue card read, 3 threads will access sqlite databases.

1. SQLEventThread. This thread will write event data to /DB/event.db. If generate 1 card read every 1 second, then this thread will write database 1 time every 1 second.
2. cmdParserThread. This thread will write event ack data to /DB/acks.db. If generate 1 card read every 1 second, then this thread will write database 1 time every 1 second.
3. mDNSprocessThread. This thread will search EVL downstream panel and read/write /DB/nx3.db. This thread access database frequency is not fixed.

cmdParserThread or mDNSprocessThread will cause cpu 99% issue after 1 or 2 hours continue card read.

We use code like following to access sqlite dababase.

Poco::Data::SQLite::Connector::registerConnector();
Session * psession;
psession = new Session(“SQLite”, “/DB/nx3.db”);
if(psession)
{
psession << “SELECT count()from events”, into(count), now;
}

[tenglong88]

attach another thread's backtrace FYI.

(gdb) bt
#0 0x8055c78a in __gnu_cxx::__atomic_add(int volatile*, int) ()
#1 0x8051beb4 in std::locale::locale() ()
#2 0x8053e7ec in std::basic_ostringstream<char, std::char_traits, std::allocator >::basic_ostringstream(std::_Ios_Openmode) ()
warning: (Internal error: pc 0x803d15a5 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x803d15a5 in read in psymtab, but not in symtab.)

#3 0x803d15a6 in Poco::Data::StatementImpl::StatementImpl (this=warning: (Internal error: pc 0x803d15a5 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x803d1530 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x803d15a5 in read in psymtab, but not in symtab.)

0x80b168d8, rSession=warning: (Internal error: pc 0x803d15a5 in read in psymtab, but not in symtab.)

@0x80ab3d38) at src/StatementImpl.cpp:56
#4 0x802a8ea8 in Poco::Data::SQLite::SQLiteStatementImpl::SQLiteStatementImpl (this=0x80b168d8, rSession=@0x80ab3d38, pDB=0x80abbd60)
at src/SQLiteStatementImpl.cpp:47
#5 0x802a02c2 in Poco::Data::SQLite::SessionImpl::createStatementImpl (this=0x80ab3d38) at src/SessionImpl.cpp:83
#6 0x802f2054 in Poco::Data::Session::createStatementImpl (this=0x808c16e8) at include/Poco/Data/Session.h:320
#7 0x802f6b7c in Poco::Data::Statement::reset (this=0xbbffedc4, session=@0x808c16e8) at src/Statement.cpp:86
#8 0x802f6d00 in Poco::Data::Statement::Statement (this=0xbbffedc4, session=@0x808c16e8) at src/Statement.cpp:43
#9 0x8007e214 in handleEventTrack (pEvent=0x80b045e8) at cmdParser/obj/../cmdParser.c:4538
#10 0x80082a84 in handleBinaryCmd (pBinCmd=0x80b03310, numRx=19) at cmdParser/obj/../cmdParser.c:3423
#11 0x80086bc0 in cmdParserThread (arg=0x0) at cmdParser/obj/../cmdParser.c:375
#12 0x804693a2 in pthread_start_thread (arg=0xbbfffbe0) at manager.c:310
#13 0x805b6b4a in clone ()

[aleks-f]

That's all nice and well, but we have no time to rewrite your logic in order to reproduce the problem - the burden is on you to provide (as link nicely summarizes):

Self Contained

It is important to ensure that the code given to others can be 'copied, pasted, compiled, run' so that they can help quickly and with a minimum of fuss.

This means that after the code has been copied, pasted and compiled by those helping, they can run it and see the results for themselves. It is the example of the problem.

You are much more likely to receive help if you do this.

Attaching more gdb backtraces likely won't improve chances for a solution. A SSCCE, as described above, may - while producing it, you may find problem in your code, or better understand where the problem in the library is.

[obiltschnig]

It's also possible that, given that SQLite and Poco::Data have been used quite widely and no such issue has come up yet, that this is an issue with your system or application. Maybe your SD card driver. Maybe your hardware is simply not powerful enough. Hard to tell.