SUMMARY The infamous QML problem — polishing loop may cause Kickoff to hang, effectively DOS-ing the whole plasma shell. I was typing in various queries in Kickoff's search, in fact I was looking for an app that's not installed on my system, so that it would show a "Get %appname%…" for Discover. So, at some point I scrolled all the way down through the results list, haven't found a Discover link there, and quickly typed in a new query: "gimp". Immediately after that Kickoff became unresponsive, nothing reacted to mouse hover or clicks. Since I was running Plasmashell manually, I switched to its terminal, saw the polishing loop errors, and killed the process with Ctrl+C. STEPS TO REPRODUCE Not sure. Will post in comments if I can figure it out. OBSERVED RESULT file:///home/ratijas/kde/usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/KickoffListView.qml:68:18: QML ListView: possible QQuickItem::polish() loop file:///home/ratijas/kde/usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/KickoffListView.qml:68:18: QML ListView: ListView called polish() inside updatePolish() of ListView file:///home/ratijas/kde/usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/KickoffListView.qml:68:18: QML ListView: possible QQuickItem::polish() loop file:///home/ratijas/kde/usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/KickoffListView.qml:68:18: QML ListView: ListView called polish() inside updatePolish() of ListView file:///home/ratijas/kde/usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/KickoffListView.qml:68:18: QML ListView: possible QQuickItem::polish() loop file:///home/ratijas/kde/usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/KickoffListView.qml:68:18: QML ListView: ListView called polish() inside updatePolish() of ListView [...] EXPECTED RESULT Shan't. Shouldn't. Mustn't. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.80 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.2-arch1-1 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz Memory: 15.6 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 970M/PCIe/SSE2
I see there were some recent commits to Kickoff applet after I pulled the master branch. To clarify, my versions are: - plasma-desktop: 829521b850e386f32c428f91ebb152009f5f436a - plasma-workspace: 6721c2ec92fb945ca6a380d40b9fabe29281073e - plasma-framework: a83321120e39a78d270607547da54b93e67bbd88 Also, it's kinda funny that the offending component KickoffListView.qml starts with this comment: > // ScrollView makes it difficult to control implicit size using the contentItem. > // Using EmptyPage instead.
FWIW I am strongly against self-made scrollable views and think we should always use ScrollView wherever possible, and fix any bugs they have in that component.
I tried the following: 1. search for "mido", which brings up "Get Midori Web Browser..." as well as a bunch of other entries 2. scroll to the bottom 3. select all in the search bar and replace with "gimp" I could not reproduce. Marking this as NEEDSINFO since we don't have a way to reproduce yet. (In reply to Nate Graham from comment #2) > FWIW I am strongly against self-made scrollable views and think we should > always use ScrollView wherever possible, and fix any bugs they have in that > component. This is most likely not relevant to the bug report. The problem is in ListView, not in the parent of the ListView, which is a Page.
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 experiences the same issue today: When I opened Kickoff (meta key) and typed "spee", Plasmashell froze and journalctl logged the following: ``` Feb 18 13:06:00 blackbox xdg-desktop-portal-kde[5305]: xdp-kde-background: GetAppState called: no parameters Feb 18 13:06:51 blackbox plasmashell[3163]: qt.qpa.wayland: Wayland does not support QWindow::requestActivate() Feb 18 13:06:51 blackbox plasmashell[3163]: kf.plasma.quick: Couldn't create KWindowShadow for PlasmaQuick::Dialog_QML_230(0x55a0b1991c30, name="popupWindow") Feb 18 13:06:51 blackbox plasmashell[3163]: kf.plasma.quick: Couldn't create KWindowShadow for PlasmaQuick::Dialog_QML_230(0x55a0b1991c30, name="popupWindow") Feb 18 13:06:51 blackbox plasmashell[3163]: kf.plasma.quick: Couldn't create KWindowShadow for PlasmaQuick::Dialog_QML_230(0x55a0b1991c30, name="popupWindow") Feb 18 13:06:52 blackbox plasmashell[3163]: file:///usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/KickoffListView.qml:68:18: QML ListView: possible QQuickItem::polish() loop Feb 18 13:06:52 blackbox plasmashell[3163]: file:///usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/KickoffListView.qml:68:18: QML ListView: ListView called polish() inside updatePolish() of ListView ``` The last two lines were spammed in journalctl for the rest of the time while Plasmashell was hanging for minutes: ``` Feb 18 13:06:52 blackbox plasmashell[3163]: file:///usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/KickoffListView.qml:68:18: QML ListView: possible QQuickItem::polish() loop Feb 18 13:06:52 blackbox plasmashell[3163]: file:///usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/KickoffListView.qml:68:18: QML ListView: ListView called polish() inside updatePolish() of ListView ``` SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220214 KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.8-1-default (64-bit) Graphics Platform: Wayland
There's probably some race condition regarding in which order properties and sizes are connected and propagated between each other. No idea where, though. I'd guess the presence of a bug is determined at plasmashell initialization time: when applets are being created; and there's some little chance to eventually get a combination where Kickoff hangs on search. Too bad we don't use fuzzy and monkey testing, huh…
Created attachment 147172 [details] gdb backtrace I don't know if this helps, but I ran `gdb -p $(pidof plasmashell)` and then `bt` to see what plasmashell was doing when it froze the last time today due to this issue. (I have omitted all other > 100 threads as up to thread 72 they did not contain relevant information (only threadweaving stuff) and it took quiet a time to generate backtraces for them.)
Note to my comment 7 above: The backtrace attached is much more verbose than the usual backtrace, when the bug is not happening: ``` #0 0x00007fe1b307652f in __GI___poll (fds=0x5582b91faad0, nfds=13, timeout=105) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007fe1b19d914e in g_main_context_poll (priority=<optimized out>, n_fds=13, fds=0x5582b91faad0, timeout=<optimized out>, context=0x5582b6a6ac30) at ../glib/gmain.c:4478 #2 g_main_context_iterate (context=context@entry=0x5582b6a6ac30, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4170 #3 0x00007fe1b19d926f in g_main_context_iteration (context=0x5582b6a6ac30, may_block=1) at ../glib/gmain.c:4240 #4 0x00007fe1b36d0384 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x5582b6a66960, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #5 0x00007fe1b367783b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7fff651f2ed0, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69 #6 0x00007fe1b367fb10 in QCoreApplication::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #7 0x00007fe1b3ac925c in QGuiApplication::exec() () at kernel/qguiapplication.cpp:1867 #8 0x00007fe1b44159f5 in QApplication::exec() () at kernel/qapplication.cpp:2824 #9 0x00005582b503269a in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/plasma5-workspace-5.24.2-1.1.x86_64/shell/main.cpp:238 ``` so I guess it could give a hint.
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now 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 Thank you for helping us make KDE software even better for everyone!
Still happening for me on a random basis.
Created attachment 148297 [details] gdb -p (pid of plasmashell) and bt full Here's the full stack trace of the thread with 100% CPU consumption, when it happened now under openSUSE TW.
(In reply to postix from comment #12) > Created attachment 148297 [details] > gdb -p (pid of plasmashell) and bt full > > Here's the full stack trace of the thread with 100% CPU consumption, when it > happened now under openSUSE TW. I think this may be a separate bug. There is no mention of QQuickListView or KickoffListView in the backtrace you posted.
Could you make a separate bug report? I will mark this one as NEEDSINFO again.
(In reply to Noah Davis from comment #14) > I think this may be a separate bug. There is no mention of QQuickListView or > KickoffListView in the backtrace you posted. I'm not sure if this is really a different bug. This happened when I searched something in Kickoff, and while typing in the search word: plasmashell stopped responding, journalctl -f spit out constatly "polishing loop detected" and the plasmashell main thread occupied one full CPU core. Exactly these steps and symptoms have happened together 5-6 times before. In the stacktrace, line #99 there's at least the word "polishLoopDetector" mentioned. That's why I'd say it may be a different bug, but definitely related.
> I think this may be a separate bug. There is no mention of QQuickListView or KickoffListView in the backtrace you posted. Do you have any suggestion what to check if happens again in order to gather more hints?
Ok, then maybe this is still the same bug and the original console output mentioning ListView/KickoffListView is just a bunch of somewhat misleading warnings. It's hard to tell for sure, but since stuff involving QQuickText, QQuickControl and QQuickGridLayout are in the backtraces you posted, there may be an issue in the KickoffItemDelegate involving the sizing of a Label and how it affects the implicit size of the delegate. I still do not have a way to reproduce this though, so even if I see something potentially suspicious, I have no idea if a change I make has fixed the problem. Thus, I am still leaving this as NEEDSINFO.
SUMMARY In Kubuntu 22.04.1, If I type "to-" into the Kickoff search field, Plasma seems to freeze. STEPS TO REPRODUCE In Kubuntu 22.04.1, type "to-" into the Kickoff search field. OBSERVED RESULT In Kubuntu 22.04.1, if I type "to-" into the Kickoff search field, Plasma seems to freeze: neither the Kickoff window nor anything else in the panel responds to mouse clicks. Window contents continue to update, and can bring existing windows to the foreground by clicking on them. htop reveals that plasmashell is using 100% of a core. After killing Plasma with "kill <plasmashell PID>", restarting with "kstart5 plasmashell", and then typing "to-" into the Kickoff serach field, same thing. But now, get a continuous stream of messages in the Konsole window where did "kstart5 plasmashell": file:///usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/KickoffListView.qml:68:18: QML ListView: possible QQuickItem::polish() loop file:///usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/KickoffListView.qml:68:18: QML ListView: ListView called polish() inside updatePolish() of ListView EXPECTED RESULT Plasma should not freeze. SOFTWARE/OS VERSIONS Operating System: Kubuntu 22.04.1 KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 Kernel Version: 5.15.0-52-generic (64-bit) Graphics Platform: X11 Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics
In my case, this behavior seems to go away (i.e. Kickoff behaves as it should) if I uncheck the "Recent Files" Plasma Search plugin in System Settings. Possibly because I have several files that access frequently named "to-do-*.txt"?
Have verified that by checking/unchecking "Recent Files" in Plasma Search settings I can make this issue happen/not-happen reliably.
Here are the contents of my ~/.local/share/RecentDocuments folder: taylora@mookie:~$ ll ~/.local/share/RecentDocuments/ total 36 -rw------- 1 taylora taylora 168 Dec 7 23:57 BitmapFont.h.desktop -rw------- 1 taylora taylora 171 Dec 7 23:57 'BitmapFont.m[2].desktop' -rw------- 1 taylora taylora 176 Dec 7 23:54 CharacterImage.h.desktop -rw------- 1 taylora taylora 176 Dec 7 23:54 'MacRomanString.h[2].desktop' -rw------- 1 taylora taylora 176 Dec 7 23:54 MacRomanString.h.desktop -rw------- 1 taylora taylora 178 Dec 7 23:54 'Monaco 9.png.desktop' -rw------- 1 taylora taylora 146 Dec 8 12:50 'to-do-janelia.txt[2].desktop' -rw------- 1 taylora taylora 146 Dec 8 12:31 to-do-janelia.txt.desktop -rw------- 1 taylora taylora 166 Dec 7 23:54 UIntTypes.h.desktop taylora@mookie:~$
I tried deleting the contents of that ~/.local/share/RecentDocuments folder, in hopes that would make the freeze go away, but I still get it, even after a reboot. (Maybe there's a cache I need to clear somewhere?) (Also, sorry for the multiple comments...)
OpenSUSE Leap 15.4 with KDE Plasma 5.24.4, Frameworks 5.90.0, Qt 5.15.2 In my case searching "term" breaks kickoff into the same endless loop as mentioned in the initial comment. It will not always break, but usually. I've discovered that disabling the applications plugin stops the loop from happening when I search "term". Of course I can't say if the issue is actually in that plugin or if it just triggers a bug in Kickoff. Unfortunately Kickoff without the applications plugin is fairly useless... In case anyone needed a visual example on what's happening I've uploaded an example video here: https://youtu.be/ZoGRwOctXDc
FWIW, I couldn't observe this bug since plasma 5.25? 5.26? and definitely no longer in 5.27. (In reply to patrick.wintering from comment #25) > OpenSUSE Leap 15.4 with KDE Plasma 5.24.4, Frameworks 5.90.0, Qt 5.15.2 Leap 15.5 beta is currently running. Once it comes out, it should offer a recent Plasma version [1], where the bug should be fixed. [1] https://build.opensuse.org/package/show/openSUSE:Leap:15.5:Update/kwin5
That's something to look forward to then, thanks for the tip.
Great, that's welcome news. Ivan, are you still able to reproduce this at all with Plasma 5.27.4 or later?
> Great, that's welcome news. Ivan, are you still able to reproduce this at all with Plasma 5.27.4 or later? No, /unfortunately/ haven't experienced it in a while. Maybe I should use Kickoff search more often instead of KRunner, and then I could trigger it someday…
All right well let's close it until you do, then. :)