SUMMARY krunner takes 100% of a CPU and allocates of available RAM after some specific key presses STEPS TO REPRODUCE 1. Launch krunner (Alt-F2) 2. Press a key for which there is no software installed on the system. For instance, "5" on my system. 3. Press Page-Up OBSERVED RESULT krunner uses 100% of a CPU and its RAM usage starts to grow EXPECTED RESULT No resources exhaustion SOFTWARE/OS VERSIONS Operating System: Kubuntu 25.04 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.8.3 Kernel Version: 6.16.8-061608-generic (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics Memory: 32 GiB of RAM (30.6 GiB usable) Graphics Processor: AMD Radeon 780M
__move_category_up in milou seems to be the offending function
A possibly relevant merge request was started @ https://invent.kde.org/plasma/milou/-/merge_requests/94
Git commit cac8ff46a4f67480ea532399ea5dd26aac7d9d8f by Harald Sitter. Committed on 07/10/2025 at 10:22. Pushed by sitter into branch 'master'. resultsview: refactor move_category so it doesn't deadlock - shared impl for both move directions - have a finite loop condition - break the loop when finding the first entry of a category (slightly complicated because the break condition is divergent, I've opted to handle this inside the move function. another alternative would have been to pass in an extra conditions function, but that seems just as complicated and makes for less readable code) the secret to this function working for both scenarios actually lies in the caller. the caller suplies a list of indexes and those are either ascending or descending sorted. effectively allowing us to iterate always in one direction in the move function. M +35 -29 lib/ResultsView.qml https://invent.kde.org/plasma/milou/-/commit/cac8ff46a4f67480ea532399ea5dd26aac7d9d8f
Git commit 048e2f1442fc1a119708f97664021dd5bf284c47 by Harald Sitter. Committed on 07/10/2025 at 10:27. Pushed by sitter into branch 'Plasma/6.5'. resultsview: refactor move_category so it doesn't deadlock - shared impl for both move directions - have a finite loop condition - break the loop when finding the first entry of a category (slightly complicated because the break condition is divergent, I've opted to handle this inside the move function. another alternative would have been to pass in an extra conditions function, but that seems just as complicated and makes for less readable code) the secret to this function working for both scenarios actually lies in the caller. the caller suplies a list of indexes and those are either ascending or descending sorted. effectively allowing us to iterate always in one direction in the move function. (cherry picked from commit cac8ff46a4f67480ea532399ea5dd26aac7d9d8f) Co-authored-by: Harald Sitter <sitter@kde.org> M +35 -29 lib/ResultsView.qml https://invent.kde.org/plasma/milou/-/commit/048e2f1442fc1a119708f97664021dd5bf284c47
Thank you for the quick fix!