Summary: | "QObject::disconnect: Unexpected nullptr parameter" when using battery powered Logitech mouse | ||
---|---|---|---|
Product: | [Plasma] Powerdevil | Reporter: | mdcclxv <mdcclxv> |
Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gerrit.huebbers, me, natalie_clarius, nate |
Priority: | NOR | ||
Version: | git-stable-Plasma/6.1 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/plasma/powerdevil/-/commit/b73b7dc317713d63aa4f230cb05b2bc16814bc1b | Version Fixed In: | 6.1.0 |
Sentry Crash Report: |
Description
mdcclxv
2024-05-27 21:13:16 UTC
Pretty sure the warning is a consequence, not the reason. I've seen this before, so I'll mark the bug report as confirmed. My findings so far: Regardless whether a mouse was disconnected from within an operating system (e.g. by clicking Disconnect button in the applet) or externally (such as falling asleep on its own, or flipping a physical switch OFF), whenever Solid::DeviceNotifier::deviceRemoved signal is emitted, the corresponding (by its UDI) Solid device's backend object has already been destroyed; so that Core::onDeviceRemoved handler attempts to disconnect from a null pointer which produces a warning in qobject.cpp. Given that setBackendObject(nullptr) literally deletes the backend object, trying to disconnect is pointless. I'll remove those two lines. Actually, I didn't even need to borrow a bluetooth mouse. Same code path is taken when disconnecting an Android phone, which is just as capable of reporting its battery levels. A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/371 Git commit d78ecf012f8b15e6470445251a0b319368222fff by ivan tkachenko. Committed on 01/06/2024 at 17:44. Pushed by ratijas into branch 'master'. daemon: Don't disconnect from a null object Regardless whether a Bluetooth device with a battery was disconnected from within an operating system (e.g. by clicking Disconnect button in the applet) or externally (such as falling asleep on its own, or flipping a physical switch OFF), whenever the Solid::DeviceNotifier::deviceRemoved signal is emitted, the corresponding Solid::Device's backend object has already been destroyed; so that Core::onDeviceRemoved handler attempted to disconnect from a null pointer which produces a warning. Given that right before emitting the deviceRemoved() signal, the setBackendObject(nullptr) is called which literally deletes the device's backend object, there is no need to disconnect. M +3 -4 daemon/powerdevilcore.cpp https://invent.kde.org/plasma/powerdevil/-/commit/d78ecf012f8b15e6470445251a0b319368222fff Git commit b73b7dc317713d63aa4f230cb05b2bc16814bc1b by ivan tkachenko. Committed on 02/06/2024 at 14:54. Pushed by ratijas into branch 'Plasma/6.1'. daemon: Don't disconnect from a null object Regardless whether a Bluetooth device with a battery was disconnected from within an operating system (e.g. by clicking Disconnect button in the applet) or externally (such as falling asleep on its own, or flipping a physical switch OFF), whenever the Solid::DeviceNotifier::deviceRemoved signal is emitted, the corresponding Solid::Device's backend object has already been destroyed; so that Core::onDeviceRemoved handler attempted to disconnect from a null pointer which produces a warning. Given that right before emitting the deviceRemoved() signal, the setBackendObject(nullptr) is called which literally deletes the device's backend object, there is no need to disconnect. (cherry picked from commit d78ecf012f8b15e6470445251a0b319368222fff) M +3 -4 daemon/powerdevilcore.cpp https://invent.kde.org/plasma/powerdevil/-/commit/b73b7dc317713d63aa4f230cb05b2bc16814bc1b |