In current code we would have a KConfigGroup with a dangling KConfig
deleted after the RHS for the group fetch has finished.
BUG: 394534
Plasma |
In current code we would have a KConfigGroup with a dangling KConfig
deleted after the RHS for the group fetch has finished.
BUG: 394534
Wrote minimal test case of code
It produced a valgrind warning (weirdly didn't crash though)
Modified to correct version
No longer any warnings
No Linters Available |
No Unit Test Coverage |
Buildable 85 | |
Build 85: arc lint + arc unit |
I guess KSharedConfig would work as well, that way the KConfig keeps a reference alive.
In theory yes, this is undefined behaviour and could cause everything between making a pixel slightly darker or crashing the harddrive.
In practice I doubt it - this doesn't touch any of the code related to saving.
I guess KSharedConfig would work as well, that way the KConfig keeps a reference alive.
I'm not convinced that
auto group = KSharedConfig::openConfig().group()
would be any different.
Your shared pointer still goes out of scope, the group's handle to the kconfig object is still the same.
but I can change anyway
Your shared pointer still goes out of scope, the group's handle to the kconfig object is still the same.
If I read the code correctly, the group keeps the shared pointer, which means it owns a reference.
But that bug is about the settings not being applied on login.
Comment#0 says that the settings are in fact saved correctly.