https://bugs.kde.org/show_bug.cgi?id=516170
Ivan <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from Ivan <[email protected]> --- Still present in 26.04.2 (Qt 6.11.1, BlueZ 5.86, Arch Linux). There is an additional, more severe failure mode in this same backend-toggle code that isn't captured here yet: in 26.04.2, disabling the Bluetooth backend at runtime does not just fail to persist (Comment 0) — it crashes kdeconnectd (SIGSEGV). The naming chaos is probably central to both symptoms. In 26.04.2: $ kdeconnect-cli --list-backends Bluetooth|AsyncLinkProvider|enabled LAN|LanLinkProvider|enabled Three different names are in play for the Bluetooth backend: the display name "Bluetooth", the id "AsyncLinkProvider" shown by --list-backends, and "BluetoothLinkProvider" (the token Comment 0 says gets written to disabled_providers). The only value that actually persists a disable is AsyncLinkProvider: ~/.config/kdeconnect/config [General] disabled_providers=AsyncLinkProvider Set that with the daemon stopped and the backend stays disabled across restarts (--list-backends then shows it disabled) and the daemon runs fine. The crash — passing the name exactly as --list-backends prints it: $ kdeconnect-cli --disable-backend Bluetooth error: Remote peer disconnected (exit code 1) kills the daemon (SIGSEGV) and persists nothing. (Comment 0 used `--disable-backend BluetoothLinkProvider` on 25.12 and reported a session-only effect, so this either regressed in 26.04.2 or is specific to passing the display name — either way, here it is a crash, not a no-op.) Backtrace (systemd-coredump, SIGSEGV) — in setLinkProviderState itself: #0 Daemon::setLinkProviderState(QString const&, bool) (libkdeconnectcore.so.26 + 0x72bfe) #1 Daemon::qt_metacall(QMetaObject::Call, int, void**) (libkdeconnectcore.so.26 + 0x750a7) #2 (kdeconnectd + 0x4b5f) #3 (libQt6DBus.so.6 + 0x44f89) <-- invoked via the D-Bus method ... #17 QCoreApplication::exec() (libQt6Core.so.6 + 0x186eaa) Starting with the backend already disabled in config does NOT crash (the provider is never constructed), so the crash is specifically in the live teardown path of setLinkProviderState — consistent with the provider-name mismatch this report is about (it looks the provider up by a name that doesn't match and operates on a missing/invalid one). Net effect: every documented way to turn this backend off is broken here — the runtime CLI crashes the daemon, and per bug 509186 the settings checkboxes do nothing — leaving manual config editing (with the AsyncLinkProvider token) as the only method that works. Happy to split the SIGSEGV into its own report and link back if you'd prefer it tracked separately; full backtrace with symbols on request. -- You are receiving this mail because: You are watching all bug changes.
