https://bugs.kde.org/show_bug.cgi?id=486848
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #13 from [email protected] --- Still reproducible on current versions (2026-11-01), so the Qt5->Qt6 / Plasma 5->6 migration did not fix this. Environment: - SteamOS holo (Valve Steam Deck, Jupiter, LCD), kernel 7.2.7-valve2-2-neptune - Plasma 6.7.3 (Wayland), kdeconnect 26.04.3, qt6-base 6.11.1, bluez 5.87, plasma-workspace 6.7.3 - 3 peers paired over Bluetooth that also run kdeconnectd (1 Windows desktop, 2 Android phones); all 3 are also reachable over LAN Symptom: kdeconnectd SIGSEGVs roughly every 10-30 minutes while the machine is completely idle (measured: 6 crashes in 90 minutes). The D-Bus-activated unit restarts it, so it is mostly noticed as silently stalled transfers/notifications. Backtrace (coredumpctl info, the BT provider's thread): #0 QRingBuffer::chop(long) libQt6Core.so.6 #1 QIODevicePrivate::read(char*, long long, bool) libQt6Core.so.6 #2 QIODevice::readLineData(char*, long long) libQt6Core.so.6 #3 QIODevicePrivate::readLine(char*, long long, ReadLineOption) libQt6Core.so.6 #4 QIODevice::readLineInto(QByteArray*, long long) libQt6Core.so.6 #5 QIODevice::readLine(long long) libQt6Core.so.6 #6 BluetoothLinkProvider::clientIdentityReceived(QBluetoothAddress const&, QSharedPointer<MultiplexChannel>) libkdeconnectcore.so.26 #7 ... libkdeconnectcore.so.26 #14 ... libQt6Bluetooth.so.6 #16 QLocalSocket::stateChanged(QLocalSocket::LocalSocketState) libQt6Network.so.6 #18 QAbstractSocket::disconnectFromHost() libQt6Network.so.6 #19 QAbstractSocketPrivate::canReadNotification() libQt6Network.so.6 #21 QApplicationPrivate::notify_helper(...) libQt6Widgets.so.6 #26 g_main_context_iteration libglib-2.0.so.0 #27 QEventDispatcherGlib::processEvents(...) libQt6Core.so.6 Note the entry point is now BluetoothLinkProvider::clientIdentityReceived() instead of serverDataReceived() as in comment #0, but frames #0-#5 and #16-#19 are identical, so it is the same defect reached from a second call site. Journal, 20 s before the crash: 12:49:56 kdeconnectd: void QBluetoothSocketPrivateBluez::_q_readNotify() 41 error: -1 "Connection reset by peer" 12:49:56 kdeconnectd: BluetoothLinkProvider::serverDataReceived socket is not readable, bailing out 12:50:16 systemd: dbus-:[email protected]: Main process exited, code=dumped, status=11/SEGV So serverDataReceived() does have a working "socket is not readable" guard - it logged and bailed. The crash comes 20 s later from clientIdentityReceived(), which appears to have no equivalent guard and calls readLine() on the already-dead channel. Adding a state/canReadLine() check there would likely fix it. Workaround that eliminated the crashes for us (Bluetooth stays ON, so mouse/keyboard/headset keep working): bluetoothctl remove <MAC-of-each-kdeconnect-peer> pkill -x kdeconnectd # D-Bus restarts it Result: 0 new crashes over 37 minutes, kdeconnectd PID unchanged, adapter still Powered: yes, LAN peers still paired and reachable. Control group: 6 SIGSEGV in the preceding 90 minutes. The crash needs a Bluetooth-paired kdeconnect peer - adapter on with ordinary peripherals is not enough. Related: there is no supported way to disable only the Bluetooth link provider - no disabled_providers key, only the internal BluetoothLinkProvider::disable() symbol. An opt-out setting would be a useful mitigation for anyone who cannot drop the BT pairing. (Also adding myself to CC so I can test a fix.) -- You are receiving this mail because: You are watching all bug changes.
