Reproducible: Always Steps to Reproduce: 1. Click on "Default" tab top left, pick "Add widgets" 2. Type "mä" to "Search" box. 3. Watch plasmashell hang with 100% cpu usage
Created attachment 100174 [details] strace of actions which led to the hang
Created attachment 100175 [details] gdb bt of all threads of plasmashell at the time of hanging
The search text "mä" is for "märkmed", which means notes. When I search for "rkmed", the "Märkmed" (notes) widget shows up just fine. If there is anything else I can help you with, I am all ears.
When starting it with: LANG=C LC_ALL=C plasmashell no hang occurs, so it definitely is localization specific.
what's your normal LANG and LC when you can recreate it?
LC_ALL= LANG=et_EE.UTF-8 LANGUAGE=et
Works here. and there's not much information in your backtrace, certainly nothing to do with locale itself - just it re-evaluating a height and doing some processing ready for drawing, it's certainly not "stuck". One possible guess from the backtrace, it's getting caught up in a loop of whether it should show the scrollbar or not - i.e it adds one then realises it doesn't need one so removes it that makes things thinner so it needs the scrollbar I've seen that before and it would kind of match your backtrace. It might be just that a search for "nä" happens to give exactly the wrong amount of items on your screen to cause that. I don't suppose you could test if "bä" locks up also if "nä" works on a slightly different font size? Finally if they do lock up, can you get a few backtraces so we can guess where the code is actually going. (if you type "set logging on" into gdb it will save all the info into a file so it's a bit easier)
Created attachment 100195 [details] gdb from multiple points Your explanation makes sense. The only ones which trigger it are "mä" and "är", unlike other combinations I tested such as "mõ" or "nä". So I reduced screen resolution from 1600x900 to 1368x768. Now searching for "mä" or "är" results in exactly 6 items in 3 rows, which fills up roughly about the height of the area. Like this everything works just fine. And looks like your theory was right. I had changed the height of the main panel on top. I increased the height for 2 pixels more and this way the bug does not expose itself. With 1600x900 resolution the right height for the panel for the bug to be exposed is 58 px.
Given you have gdb skills, if you want to test a patch: https://phabricator.kde.org/D2239 but don't feel you have to.
I hot-patched the right file and can confirm, this workaround definitely made the resize loop go away. Thank you! Maybe the resize loop needs something like resize attempt counter so it would always stop after a few rounds and be happy with the smaller width?
Maybe, but it's in Qt code - so we'd need a workaround anyway - and this particular component is set for replacement so it's even harder to get a change in. QtQuickControls 2 will fix it...
Makes sense. Thank you for fix and all the help. KDE rocks.
Git commit 14d48bac5f95e4e276b227023fed97d9cdeb6157 by David Edmundson. Committed on 01/08/2016 at 12:50. Pushed by davidedmundson into branch 'Plasma/5.7'. Workaround searching lockup Summary: QQC::ScrollView has an annoying bug where you can get it in a situation where if you have exactly if delegates are based on the viewport width you can get in a loop where you need the scrollbar, that shrinks the view so it resizes the delegates at which point you don't need the scrollbar, so it resizes the delegates so and so on. Keeping scrollbars always on is a good workaround. If anything it's nice to not have things jumping around slightly when searching Test Plan: Plasma explorer still works. Approach works as I've used it in the wallpaper selection dialog for exactly the same reason. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D2239 M +2 -0 desktoppackage/contents/explorer/WidgetExplorer.qml http://commits.kde.org/plasma-desktop/14d48bac5f95e4e276b227023fed97d9cdeb6157