https://bugs.kde.org/show_bug.cgi?id=524027
--- Comment #1 from Lasha Abulashvili <[email protected]> --- Hit what looks like exactly this bug on another KDE neon machine (kdeconnect 26.04.3-0zneon, Qt 6.11.1, KDE neon User Edition, kernel 7.0.0-28-generic, Plasma 6.7.3), and captured a stack of the daemon with eu-stack while it was spinning. It appears to be an infinite loop in Device::reloadPlugins() while a LanDeviceLink is being torn down. Observed state during the hang: - kdeconnectd main thread pegged at 100% of one core, ~16h of CPU accumulated before we noticed; every other thread idle in poll. - voluntary_ctxt_switches 3,893 vs nonvoluntary_ctxt_switches 1,164,373 — the main thread never yields, i.e. a tight CPU loop, not an event/reconnect storm. - D-Bus never serviced: `kdeconnect-cli -l` times out; the phone cannot reconnect (matches "kdeconnect doesn't detect it"). - Onset window matches the phone dropping off the LAN. Main thread stack (eu-stack, single sample mid-spin): #0 _int_free #1 free #2 QUrl::~QUrl() #3 kdeconnect_sftp.so+0x1ad79 #4 kdeconnect_sftp.so+0x1a77a #5 kdeconnect_sftp.so+0x1a7f2 #6 libkdeconnectcore.so.26.04.3+0xe5bef #7 libkdeconnectcore.so.26.04.3+0xe363e #8 Device::reloadPlugins() #9 Device::removeLink(DeviceLink*) #10 Device::linkDestroyed(QObject*) #11 libkdeconnectcore.so.26.04.3+0xee2af #12 libkdeconnectcore.so.26.04.3+0xeec72 #13 libkdeconnectcore.so.26.04.3+0xee323 #14 libkdeconnectcore.so.26.04.3+0xed3c8 #15 libkdeconnectcore.so.26.04.3+0xeaaf7 #16 QtCore #17 QObject::destroyed(QObject*) #18 QObject::~QObject() #19 libkdeconnectcore.so.26.04.3+0x5e5d2 #20 libkdeconnectcore.so.26.04.3+0x5e6c6 #21 libkdeconnectcore.so.26.04.3+0x5e6e6 #22 QObject::event(QEvent*) [DeferredDelete] #23 QApplicationPrivate::notify_helper #24 QCoreApplication::notifyInternal2 #25 QCoreApplicationPrivate::sendPostedEvents #26+ glib event loop → QCoreApplication::exec → main Anonymous frames resolved with addr2line against the shipped (non-dbgsym) libs, so these are nearest-exported-symbol only — offsets above are the authoritative part: - #19–#21 resolve nearest LanDeviceLink::qt_metacall — the object under deferred deletion at #18 is a LanDeviceLink. - #14/#15 resolve nearest std::_Rb_tree<QString, KdeConnectPlugin*>::_M_insert_equal_lower / _M_insert_equal_ — i.e. plugin-multimap manipulation under reloadPlugins(). - #3–#5 in kdeconnect_sftp.so resolve nearest std::_Rb_tree<QString, QVariant>::_M_insert_ (plugin config QVariantMap handling), beneath a QUrl destructor. So the shape is: ~LanDeviceLink (deferred delete, i.e. the phone's link going away) → QObject::destroyed → Device::linkDestroyed → Device::removeLink → Device::reloadPlugins → sftp plugin config/teardown — and it never returns. The ctx-switch numbers say this single call chain ran for ~16 hours, which smells like a plugin container being mutated mid-iteration (both hot spots sit in rb-tree code). Recovery: plain SIGTERM terminates it fine and a restart reconnects the phone immediately. This box also logged bluez adapter-flap messages beforehand ("Device discovery aborted due to unexpected adapter changes from another process." / "No local bluetooth adapter found"), but the loop itself is clearly in LAN/plugin teardown code. It recurs every few days here; happy to provide the full /proc maps, additional eu-stack samples on the next occurrence, or a re-resolution against dbgsym packages if useful. -- You are receiving this mail because: You are watching all bug changes.
