https://bugs.kde.org/show_bug.cgi?id=389492
Bug ID: 389492
Summary: Infinite loop in sqlite3BtreeCursor
Product: kactivitymanagerd
Version: 5.11.5
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: ivan.cu...@kde.org
Reporter: pe...@cordes.ca
CC: plasma-b...@kde.org
Target Milestone: ---
After upgrading my Arch Linux desktop earlier today (no packages held-back or
anything), I have kactivitymanagerd 5.11.5-1 and sqlite 3.22.0-1.
I noticed after starting X (from a text console with /usr/bin/startx
/usr/bin/startkde like I usually do) that kactivitymanagerd had 2 threads
running at 100%. IDK how long this had been going on for, but probably since
starting KDE because I don't even have a CPU-usage plasma widget on my taskbar,
and hadn't opened the task manager / process list.
This may not be a kactivitymanagerd bug at all, unless calling sqlite functions
with the wrong args can get threads stuck in the pointer-chasing loop in
sqlite3BtreeCursor. (https://www.sqlite.org/src/artifact/656173030bd10759:
for(pX=pBt->pCursor; pX; pX=pX->pNext){
if( pX->pgnoRoot==(Pgno)iTable ){
pX->curFlags |= BTCF_Multiple;
pCur->curFlags |= BTCF_Multiple;
}
}
pX->pNext is pointing to itself, so the mov rax,QWORD PTR [rax+0x18] asm
instruction is loading the same value repeatedly. (I don't have debug symbols,
but the asm loop it's stuck in is very clearly from that part of the source).
The if() condition is false, so it's not ORing anything.
The object pointed to by pX is:
(gdb) x /8g $rax
0x55e6161c19e8: 0x0000000002022201 0x000055e616102d10
0x55e6161c19f8: 0x000055e6160d4850 0x000055e6161c19e8
0x55e6161c1a08: 0x0000000000000000 0x000000000000005f
0x55e6161c1a18: 0x000055e616141529 0x0060005f0000005f
(note the 3rd qword is the pointer pointing to the start of the object).
The backtrace on that thread is:
#0 0x00007fb9f1053e13 in sqlite3BtreeCursor () from /usr/lib/libsqlite3.so.0
#1 0x00007fb9f10e08d4 in sqlite3VdbeExec () from /usr/lib/libsqlite3.so.0
#2 0x00007fb9f10e7550 in sqlite3_step () from /usr/lib/libsqlite3.so.0
#3 0x00007fb9f1345a2e in ?? () from
/usr/lib/qt/plugins/sqldrivers/libqsqlite.so
#4 0x00007fb9f1346c13 in ?? () from
/usr/lib/qt/plugins/sqldrivers/libqsqlite.so
#5 0x00007fb9f155e878 in QSqlQuery::exec() () from /usr/lib/libQt5Sql.so.5
#6 0x00007fb9f179fc18 in ?? () from
/usr/lib/qt/plugins/kactivitymanagerd/1/kactivitymanagerd_plugin_sqlite.so
#7 0x00007fb9f17a04df in ?? () from
/usr/lib/qt/plugins/kactivitymanagerd/1/kactivitymanagerd_plugin_sqlite.so
#8 0x00007fb9f17a0588 in ?? () from
/usr/lib/qt/plugins/kactivitymanagerd/1/kactivitymanagerd_plugin_sqlite.so
#9 0x00007fb9f17a142a in ?? () from
/usr/lib/qt/plugins/kactivitymanagerd/1/kactivitymanagerd_plugin_sqlite.so
#10 0x00007fb9f17b492a in ?? () from
/usr/lib/qt/plugins/kactivitymanagerd/1/kactivitymanagerd_plugin_sqlite.so
#11 0x00007fba12124932 in QObject::event(QEvent*) () from
/usr/lib/libQt5Core.so.5
#12 0x00007fba12e38e3c in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /usr/lib/libQt5Widgets.so.5
#13 0x00007fba12e40816 in QApplication::notify(QObject*, QEvent*) () from
/usr/lib/libQt5Widgets.so.5
#14 0x00007fba120f36c0 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() from /usr/lib/libQt5Core.so.5
#15 0x00007fba120f6326 in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#16 0x00007fba1214cca6 in
QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /usr/lib/libQt5Core.so.5
#17 0x00007fba09de958e in ?? () from /usr/lib/libQt5XcbQpa.so.5
#18 0x00007fba120f1d0b in
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
/usr/lib/libQt5Core.so.5
#19 0x00007fba120faff8 in QCoreApplication::exec() () from
/usr/lib/libQt5Core.so.5
#20 0x000055e6145abf6f in ?? ()
#21 0x00007fba11739f4a in __libc_start_main () from /usr/lib/libc.so.6
#22 0x000055e6145ac1ca in _start ()
Sorry I don't have debug symbols. This report probably isn't enough to really
debug anything, but if other people are hitting the same bug then maybe we can
figure out which versions of kactivitymanagerd + libraries are a problem.
It appears the other infinite-loop thread is *also* stuck in the same function:
(gdb) info thread
Id Target Id Frame
* 1 Thread 0x7fba13fc5e00 (LWP 726) "kactivitymanage" 0x00007fb9f1053e1d in
sqlite3BtreeCursor () from /usr/lib/libsqlite3.so.0
2 Thread 0x7fba06fb3700 (LWP 727) "QXcbEventReader" 0x00007fba1180497b in
poll () from /usr/lib/libc.so.6
3 Thread 0x7fb9f89d7700 (LWP 737) "QDBusConnection" 0x00007fba11804a76 in
ppoll () from /usr/lib/libc.so.6
4 Thread 0x7fb9f3ddf700 (LWP 743) "QThread" 0x00007fba11804a76 in ppoll ()
from /usr/lib/libc.so.6
5 Thread 0x7fb9f35de700 (LWP 747) "QThread" 0x00007fba11804a76 in ppoll ()
from /usr/lib/libc.so.6
6 Thread 0x7fb9f2ddd700 (LWP 748) "QThread" 0x00007fba11804a76 in ppoll ()
from /usr/lib/libc.so.6
7 Thread 0x7fb9e3ded700 (LWP 14475) "QThread" 0x00007fb9f1053e10 in
sqlite3BtreeCursor () from /usr/lib/libsqlite3.so.0
(After several continue / control-C cycles, info thread always shows the same
thing. Fun fact: right down to the same instruction in that loop almost
always, because out-of-order execution bottlenecks on the pointer-chasing load,
so that's almost always the first not-retired instruction when an interrupt
arrives.)
--
You are receiving this mail because:
You are watching all bug changes.
