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.)