Created attachment 177622 [details] Full list of updates after which the bug happened *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports Please remove this comment after reading and before submitting - thanks! *** SUMMARY After some updates (see attached list), and after rebooting, plasmashell does not show up anymore after logging in. It seems stuck in some kind of infinite loop. STEPS TO REPRODUCE 1. Install updates 2. Reboot 3. Log in OBSERVED RESULT The splash screen is shown for a rather long time. When it disappears, the desktop is black with only the cursor shown. KWin is working correctly (can open terminal through global shortcuts, windows etc. are fine). EXPECTED RESULT Start up plasmashell normally SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Tumbleweed 20250121 DE Plasma Version: 6.2.90 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 ADDITIONAL INFORMATION plasmashell is running at 100% of one CPU core. I tried interrupting the process to see where it got stuck. I am not too versed in gdb, but was not able to get further than `QQuickItem::setParentItem` (see attached backtrace).
Created attachment 177623 [details] gdb backtrace of plasmashell process Sorry, I hit enter a little too early, without removing the "please remove" banner
Important parts of the backtrace: #6 0x000055a3f15cb0b2 in ShellCorona::addOutput (this=0x55a404409210, screen=0x55a403f38880) at /usr/src/debug/plasma-workspace-6.2.90/shell/shellcorona.cpp:1476 #7 ShellCorona::addOutput (this=0x55a404409210, screen=0x55a403f38880) at /usr/src/debug/plasma-workspace-6.2.90/shell/shellcorona.cpp:1438 #8 0x000055a3f15d2aaa in ShellCorona::load (this=0x55a404409210) at /usr/src/debug/plasma-workspace-6.2.90/shell/shellcorona.cpp:841 #9 0x00007f4f4c00db21 in QtPrivate::QSlotObjectBase::call (this=0x55a40442ee30, r=<optimized out>, a=0x7ffc8eb37450, this=<optimized out>, r=<optimized out>, a=<optimized out>) at /usr/src/debug/qtbase-everywhere-src-6.8.1/src/corelib/kernel/qobjectdefs_impl.h:486 #10 doActivate<false> (sender=0x55a404407150, signal_index=4, argv=0x7ffc8eb37450) at /usr/src/debug/qtbase-everywhere-src-6.8.1/src/corelib/kernel/qobject.cpp:4124 #11 0x00007f4f4e08c7e1 in KActivities::Consumer::serviceStatusChanged(KActivities::Consumer::ServiceStatus) () at /lib64/libPlasmaActivities.so.6 #12 0x00007f4f4c00db21 in QtPrivate::QSlotObjectBase::call (this=0x55a40462cda0, r=<optimized out>, a=0x7ffc8eb37600, this=<optimized out>, r=<optimized out>, a=<optimized out>) at /usr/src/debug/qtbase-everywhere-src-6.8.1/src/corelib/kernel/qobjectdefs_impl.h:486 #13 doActivate<false> (sender=0x55a404409820, signal_index=11, argv=0x7ffc8eb37600) at /usr/src/debug/qtbase-everywhere-src-6.8.1/src/corelib/kernel/qobject.cpp:4124 #14 0x00007f4f4e09a72b in ??? () at /lib64/libPlasmaActivities.so.6 #15 0x00007f4f4e09f1d4 in ??? () at /lib64/libPlasmaActivities.so.6
Do you or did you have multiple screens? It looks suspiciously like Bug 421700. Are you using the Wayland or X11 session? Does it happen in both session types, or only one?
(In reply to Nate Graham from comment #3) > Do you or did you have multiple screens? It looks suspiciously like Bug > 421700. > > Are you using the Wayland or X11 session? Does it happen in both session > types, or only one? I do have an external screen, and realize I had not tried without. But I have further updates: after a while (10+ minutes), different elements started popping up slowly (the Preview Banner, then the desktop, and finally the panel. And there's something more which I did not remember: in my last session I had 3 sticky notes that were created containing ELF binaries (most likely Qt libraries which I was working with. I did not create them intentionally, nor did I manage to close them, so I thought they would go away with a new session. When I was interrupting the plasmashell process, it was often in some text layout or harfbuzz functions. So I guess the process was busy doing the layout for the sticky notes instead of actually getting the session ready. Besides the fact that I could disable, remove or not create immense sticky notes if I was more careful, I think the fact that it can almost completely block the plasmashell process is still an issue.
I am usually using the wayland session, but it is the same with X11. This can be reproduced by creating a number of sticky notes containing ELF files.
I verified again that this happens with any text. If it is long enough (like a few MB), there is a noticeable delay before the desktop appears. I suppose the sticky notes business should happen in a separate thread, or at least it should not do the layout for the whole in a blocking manner. Though of course such big sticky notes shouldn't happen in common use cases.
There's also no reason a few megabytes of text should result in a noticeable launch delay.
I can reproduce this. If I paste 6 MB of text into a sticky Note widget and restart plasmashell, it slows down plasmashell's startup in exactly the way described here. The degree of slowness is not as high; for me it loads after about 15 seconds, not 10 minutes. But clearly something fishy is going on, and there's room for performance optimization.