Created attachment 153237 [details] screenshot of 1st, 2nd run and incorrect list SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. run plasma system monitor and edit page in overview 2. add column and configure sensor OBSERVED RESULT sensor list are changed every time when run system monitor and not correct. for example - select "disk", it shows sensor for cpu or select "network", it shows sensors for gpu. EXPECTED RESULT it shows correct sensor list SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.26.2 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Kernel Version: 6.0.2-arch1-1 (64-bit) Graphics Platform: X11 Processors: 16 × 12th Gen Intel® Core™ i5-12500H Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® Graphics and Nvidia RTX 3050 Ti for laptop.
it's also reproduced on kde neon.
Created attachment 153348 [details] log I attached a log.
This bug is not rerproduced on kubuntu 22.10 (plasma 5.26.2 with kubuntu ppa) and opensuse, but still arch linux and kde neon. Is this caused by build environment differences?
Can you attach the output of 'kstatsviewer --list | sort '?
Created attachment 155210 [details] the output of kstatsiviewer Here is the output of kstatsviewer this bug is still reproduced. Operating System: Arch Linux KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.8 Kernel Version: 6.1.4-arch1-1 (64-bit) Graphics Platform: X11 Processors: 16 × 12th Gen Intel® Core™ i5-12500H Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® Graphics Manufacturer: HP Product Name: Victus by HP Laptop 16-d1xxx
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
I have changed language in regional settings from C to american english, It's working!
That's a workaround, not a solution. Sensors should be displayed correctly regardless of locale settings. I can confirm that it's the C locale that is causing the issue, specifically LC_COLLATE. With LC_COLLATE set to C or C.UTF-8 the issue is present, with other values (I checked en_US.UTF-8 and en_IE.UTF-8) sensor list is correct. This used to work some time ago even with C locale; I've been using LC_COLLATE=C for years, and I remember when systemmonitor was first introduced (Plasma 5.22) this issue did not occur. I guess it could also be a glibc regression/feature, since there were changes in this area recently (e.g. addition of C.UTF-8 locale in glibc 2.35). I attached outputs of 'kstatsviewer --list | sort' for both C.UTF-8 and en_US.UTF-8.
Created attachment 157632 [details] LC_COLLATE=C.UTF-8
Created attachment 157633 [details] LC_COLLATE=en_US.UTF-8
I notice with C that `cpu`, `gpu`are at the bottom, otherwise on top
(In reply to Maciej Stanczew from comment #10) > Created attachment 157633 [details] > LC_COLLATE=en_US.UTF-8 Switching C to en_US.UTF-8 in file ~/.config/plasma-localerc helped me.
*** Bug 472442 has been marked as a duplicate of this bug. ***
Created attachment 160781 [details] sensors: Correctly handle the return value of QCollator::compare I think I have found the root cause for this issue: it's in libksysguard, and was introduced with the fix to bug #440310. First, I located the place in the code which is impacted by changing between en_US and C locales: it's the Compare structure in SensorTreeModel.cpp, and its use as a comparator in an std::map in SensorTreeItem: > std::map<QString, std::unique_ptr<SensorTreeItem>, Compare> children; After adding some debug logs I noticed a weird behavior. Calls to Compare() seemed ok with en_US, but with the C locale I was getting a 'false' result regardless of the order of arguments: > # with LC_COLLATE=en_US.UTF-8 > Compare("cpu", "lmsensors") = true > Compare("lmsensors", "cpu") = false > # with LC_COLLATE=C.UTF-8 > Compare("cpu", "lmsensors") = false > Compare("lmsensors", "cpu") = false Adding more information to the logs revealed the cause of this behavior: > # with LC_COLLATE=en_US.UTF-8 > Compare("cpu", "lmsensors") = true, collator->compare() = -1 > Compare("lmsensors", "cpu") = false, collator->compare() = 1 > # with LC_COLLATE=C.UTF-8 > Compare("cpu", "lmsensors") = false, collator->compare() = -9 > Compare("lmsensors", "cpu") = false, collator->compare() = 9 We can see that with the C locale, 'collator->compare()' returns the lexicographical difference between characters (e.g. 'c' - 'l' = -9), and with en_US it squashes the value to -1. And since the code in Compare only checks against -1, all the other negative values are not handled correctly: > return collator->compare(first, second) == -1; Documentation about QCollator::compare() doesn't restrict the return value to [-1, 0, 1]: > Returns an integer less than, equal to, or greater than zero depending on whether s1 sorts before, with or after s2. Thus comparing the returned value against -1 is based on an incorrect assumption, which just happens to work with most locales, but breaks with the C locale. If I'm not missing anything, the fix should be easy enough: change "== -1" to "< 0". I have prepared a patch based on 5.27.7 and tested it on my setup, and I get correct sensor list even with 'LC_COLLATE=C.UTF-8'.
*** Bug 473139 has been marked as a duplicate of this bug. ***
Ooh, nice investigation and good catch Maciej Stanczew. The QCollator documentation isn't exactly clear on the values that are returned. Would you mind doing a merge request on invent.kde.org with that patch?
Sure. Should the merge request be for master or Plasma/5.27? (Note that I'm only able to test it on the 5.27 branch.)
This can be easily reproduced with: (export LANG=C; plasma-systemmonitor) (In reply to Maciej Stanczew from comment #17) > Sure. Should the merge request be for master or Plasma/5.27? (Note that I'm > only able to test it on the 5.27 branch.) Master. I'll test it there and merge, and cherry-pick it to 5.27 for you. :) Make sure to include: BUG: 461070 in the commit and MR description.
Please note, Maciej, that Plasma 5.26.8 will release on the 12th of September (1 month from now), so you'll need to submit your MR before then to cherry-pick.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libksysguard/-/merge_requests/285
Git commit bf2685a3628f213e930743676a6d713e630c6a59 by Oliver Beard, on behalf of Maciej Stanczew. Committed on 13/08/2023 at 15:19. Pushed by olib into branch 'Plasma/5.27'. sensors: Correctly handle the return value of QCollator::compare QCollator::compare() can return any integer, not just [-1, 0, 1]. Comparing the result with -1 happened to work with most locales, but it broke with the C locale. As a result, when sensors were put into std::map, they were sometimes erroneously treated as duplicates, leading to a randomly incomplete and garbled sensor list. (cherry picked from commit 0a7efca4b331eb9619a2a88fe9093cbbbd351b6e) M +1 -1 sensors/SensorTreeModel.cpp https://invent.kde.org/plasma/libksysguard/-/commit/bf2685a3628f213e930743676a6d713e630c6a59