https://bugs.kde.org/show_bug.cgi?id=484019
--- Comment #19 from Thomas Berger <l...@lokis-chaos.de> ---
Yeah, that proved some of my assumptions yesterday:
The object is the same allocated from
```
void LinuxCpuObject::makeSensors()
{
BaseCpuObject::makeSensors();
m_frequency = new KSysGuard::SensorProperty(QStringLiteral("frequency"),
this);
if (!m_temperature) {
m_temperature = new
KSysGuard::SensorProperty(QStringLiteral("temperature"), this);
}
}
```
And the vtable clearly shows that we are using the base class.
This led me down the correct path:
- We define a Sensor via makeSensorsFeatureSensor for each CPU on the first
found k10temp chip
- for the other found chips, we override the newly created sensors with null
ptrs
This happens, because a property is added on sensor creation to our
SensorObject (in this case the LinuxCpuObject). `makeSensorsFeatureSensor`
bails out, if the sensor already exists on our SensorObject. And it does, we
just created it.
If makeSensorsFeatureSensor bails out, a nullptr is returned.
After the call to addSensors, that leads down to the creation of our
temperature sensors, `initialize` is called oin all cpu objects, adding the
"missing" sensors with default implementations.
While there are multiple ways to fix this, none of them seems like a good idea.
We would have to map the temperatures to the cores on the appropriate DIE, or
the user looses important information (imagine one DIE sitting near the upper
limit because of an thermal/contact issue, but the first DIE is ok ....).
I would propose that we wait how the discussion in
https://bugs.kde.org/show_bug.cgi?id=490675 plays out, before taking actions
here.
Thx btw, now i learned something new today!
--
You are receiving this mail because:
You are watching all bug changes.
