https://bugs.kde.org/show_bug.cgi?id=523562
Méven <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|ASSIGNED |RESOLVED Latest Commit| |https://invent.kde.org/plas | |ma/libksysguard/-/commit/e7 | |2f83052f8a8191239831125c75b | |d0e59d004c8 --- Comment #3 from Méven <[email protected]> --- Git commit e72f83052f8a8191239831125c75bd0e59d004c8 by Méven Car. Committed on 27/07/2026 at 17:43. Pushed by ngraham into branch 'master'. systemstats: don't keep dangling SensorObject pointers in SensorContainer A SensorObject was only removed from its SensorContainer when it emitted aboutToBeRemoved; the destructor did neither that nor any deregistration. An object deleted by any other route (directly, or by its QObject parent) therefore left a dangling raw pointer in the container. When another object was later added, objectAdded triggered AggregateSensor::updateSensors(), which iterates objects() and calls id() on each, dereferencing the freed object and crashing in the QString copy. Connect each object's QObject::destroyed to drop it from the container, comparing by identity so re-adding an object with the same id is unaffected. Also register objects with the object itself as the queued-call context, so an object destroyed before its queued addObject() runs no longer calls addObject() on a dangling pointer. M +1 -0 autotests/CMakeLists.txt A +85 -0 autotests/sensorcontainertest.cpp [License: LGPL(v2.0+)] M +6 -0 systemstats/SensorContainer.cpp M +1 -1 systemstats/SensorObject.cpp https://invent.kde.org/plasma/libksysguard/-/commit/e72f83052f8a8191239831125c75bd0e59d004c8 -- You are receiving this mail because: You are watching all bug changes.
