Bug 447717

Can reproduce on both Arch Linux and neon unstable. This crash was previously mentioned in bug 439681 comment 6.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.89.0
Qt Version: 5.15.2
Graphics Platform: Wayland

Created attachment 145009 [details]
WAYLAND_DEBUG=1 crash output

Added log file of the last 1000 lines of crash terminal output when run with WAYLAND_DEBUG set. Unsure if it's of any extra help.

This also happens to me.

I even have task bar tooltips turned off, in the hopes that it would stop these crashes. Which it did for a while, but now they are back.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Manjaro x86_64
KDE Plasma Version: 5.23.4
KDE Frameworks Version: 5.89.0
Qt Version: 5.15.2
Graphics platform: Wayland

Can you also post kwin_wayland's log after a crash? The log is in ~/.local/share/sddm/wayland-session.log

Can you also check how many file descriptors kwin has open (before the crash)?

  sudo ls /proc/(pidof kwin_wayland)/fd | wc -l

Created attachment 145370 [details]
wayland-session.log after a fresh login and induced crash

Attaching wayland-session.log.

Number of open file descriptors before the crash was 257.

*** Bug 445409 has been marked as a duplicate of this bug. ***

*** Bug 445778 has been marked as a duplicate of this bug. ***

Created attachment 145559 [details]
wayland-session.log at around crash time

This is a snippet of the log from around the crash time. My log is pretty long, because some application spam it, so I tried to only include what could be relevant.

*** Bug 449194 has been marked as a duplicate of this bug. ***

Created attachment 145953 [details]
WAYLAND_DEBUG=1 plasmashell crash log.log

After I crazily move my cursor among diferent tasks to show window thumbnails in tooltips. It seems there is a maximum number of screen casting requests a program can make.

coredumpctl shows no record on the crash.

STEPS TO REPRODUCE
1. Login to a Wayland session
2. Move the cursor to hover on different tasks to show tooltips repeatedly

Thanks for @JR for finding the way to trigger this bug. I see it recently (I switched to wayland recently) but had no idea why this happened.

In the meantime, I also found this bug report and fix for SwayWM: https://github.com/swaywm/wlroots/issues/2594 .
They seem to have found a cause and the way to fix it. Probably useful for Plasma too?

Somtimes it starts doing this when I'm not really doing anything to aggravate it, and it just keeps continuing randomly crashing until I reboot.

> apr 17 16:09:02 newxps kwin_wayland[1121]: kwin_screencast: PipeWire remote error:  connection error
> apr 17 16:09:02 newxps kwin_wayland_wrapper[1121]: file descriptor expected, object (752), message add(huuuuu)
> apr 17 16:09:02 newxps kwin_wayland_wrapper[1121]: error in client communication (pid 799855)
> apr 17 16:09:02 newxps kwin_wayland[1121]: QMetaProperty::read: Unable to handle unregistered datatype 'KWin::SessionState' for property 'KWin::EffectsHandlerImpl::sessionState'
> apr 17 16:09:02 newxps plasmashell[799855]: wl_display@1: error 1: invalid arguments for zwp_linux_buffer_params_v1@752.add
> apr 17 16:09:02 newxps plasmashell[799855]: The Wayland connection experienced a fatal error: Invalid argument
> apr 17 16:09:02 newxps fcitx5[1312]: I2022-04-17 16:09:02.587769 kimpanel.cpp:117] Kimpanel new owner
> apr 17 16:09:02 newxps systemd[1002]: plasma-plasmashell.service: Main process exited, code=exited, status=1/FAILURE
> apr 17 16:09:02 newxps systemd[1002]: plasma-plasmashell.service: Failed with result 'exit-code'.
> apr 17 16:09:02 newxps systemd[1002]: plasma-plasmashell.service: Consumed 26.165s CPU time.
> apr 17 16:09:02 newxps systemd[1002]: plasma-ksystemstats.service: Consumed 3.072s CPU time.
> apr 17 16:09:02 newxps systemd[1002]: plasma-plasmashell.service: Scheduled restart job, restart counter is at 7.
> apr 17 16:09:02 newxps systemd[1002]: Stopped KDE Plasma Workspace.

The counter is up to 9 now since the time I copied it, often bringing Firefox down with it. Very disruptive.

Can I get a log of "strace plasmashell --replace" if this is still an issue?

Created attachment 148584 [details]
plasmashell strace

Certainly.

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!

This crash persists on Plasma 5.25 beta, Arch Linux.

*** Bug 460311 has been marked as a duplicate of this bug. ***

try as I might, I can't reproduce when running plasmashell with WAYLAND_DEBUG=1 from the command line:

WAYLAND_DEBUG=1 plasmashell --replace </dev/null &>~/Desktop/ab.txt

but when I run plasma 'normally', I can repro easily.

I have been hitting this bug constantly on 5.26.2

(In reply to Nathan from comment #20)
> I have been hitting this bug constantly on 5.26.2

Same here, plasma 5.26.2

org.kde.plasma.libtaskmanager: Got invalid activation app_id: ""
Service  ":1.130" unregistered
kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x1a8d760)
kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x1a8d760)
kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x1a8d760)
kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x1a8d760)
message too short, object (313), message set_app_id(s)
error in client communication (pid 1485)
wl_display@1: error 1: invalid arguments for xdg_activation_token_v1@313.set_app_id
The Wayland connection experienced a fatal error: Argument invalide
Service  "org.kde.StatusNotifierHost-1485" unregistered

Mine error is a little different but very similar

Nov 04 07:02:00 nathan-hp1030G4 systemd[1794]: Started plasma-plasmashell.service - KDE Plasma Workspace.
Nov 04 07:02:00 nathan-hp1030G4 systemd[1794]: Starting plasma-plasmashell.service - KDE Plasma Workspace...
Nov 04 07:02:00 nathan-hp1030G4 systemd[1794]: plasma-plasmashell.service: Consumed 14.464s CPU time.
Nov 04 07:02:00 nathan-hp1030G4 systemd[1794]: Stopped plasma-plasmashell.service - KDE Plasma Workspace.
Nov 04 07:02:00 nathan-hp1030G4 systemd[1794]: plasma-plasmashell.service: Scheduled restart job, restart counter is at 1.
Nov 04 07:01:59 nathan-hp1030G4 systemd[1794]: plasma-plasmashell.service: Consumed 14.464s CPU time.
Nov 04 07:01:59 nathan-hp1030G4 systemd[1794]: plasma-plasmashell.service: Failed with result 'exit-code'.
Nov 04 07:01:59 nathan-hp1030G4 systemd[1794]: plasma-plasmashell.service: Main process exited, code=exited, status=1/FAILURE
Nov 04 07:01:59 nathan-hp1030G4 plasmashell[2150]: The Wayland connection experienced a fatal error: Invalid argument
Nov 04 07:01:59 nathan-hp1030G4 plasmashell[2150]: wl_display@1: error 1: invalid arguments for zwp_linux_dmabuf_v1@25.get_surface_feedback
Nov 04 07:01:59 nathan-hp1030G4 kwin_wayland_wrapper[1884]: error in client communication (pid 2150)
Nov 04 07:01:59 nathan-hp1030G4 kwin_wayland_wrapper[1884]: unknown object (48), message get_surface_feedback(4no)
Nov 04 07:01:51 nathan-hp1030G4 plasmashell[2150]: kf.plasma.quick: Couldn't create KWindowShadow for Osd_QMLTYPE_952(0x55c06e3d7dc0)
Nov 04 07:01:51 nathan-hp1030G4 plasmashell[2150]: kf.plasma.quick: Couldn't create KWindowShadow for Osd_QMLTYPE_952(0x55c06e3d7dc0)
Nov 04 07:01:51 nathan-hp1030G4 plasmashell[2150]: kf.plasma.quick: Couldn't create KWindowShadow for Osd_QMLTYPE_952(0x55c06e3d7dc0)
Nov 04 07:01:51 nathan-hp1030G4 plasmashell[2150]: kf.plasma.quick: Couldn't create KWindowShadow for Osd_QMLTYPE_952(0x55c06e3d7dc0)
Nov 04 07:01:51 nathan-hp1030G4 plasmashell[2150]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:221:21: QML SelectableLabel: Binding loop detected for property "implicitWidth"
Nov 04 07:01:51 nathan-hp1030G4 plasmashell[2150]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/SelectableLabel.qml:38:5: QML TextArea: Binding loop detected for property "implicitHeight"
Nov 04 07:01:51 nathan-hp1030G4 plasmashell[2150]: file:///usr/lib64/qt5/qml/org/kde/plasma/components.3/ScrollView.qml:45:27: QML ScrollBar: Binding loop detected for property "visible"
Nov 04 07:01:51 nathan-hp1030G4 plasmashell[2150]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:221:21: QML SelectableLabel: Binding loop detected for property "implicitHeight"
Nov 04 07:01:51 nathan-hp1030G4 plasmashell[2150]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:221:21: QML SelectableLabel: Binding loop detected for property "implicitWidth"
Nov 04 07:01:51 nathan-hp1030G4 plasmashell[2150]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:221:21: QML SelectableLabel: Binding loop detected for property "implicitWidth"
Nov 04 07:01:51 nathan-hp1030G4 plasmashell[2150]: Could not find the Plasmoid for Plasma::FrameSvgItem(0x55c06e6f18a0) QQmlContext(0x55c06d7f8570) QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Nov 04 07:01:51 nathan-hp1030G4 plasmashell[2150]: Could not find the Plasmoid for Plasma::FrameSvgItem(0x55c06e6f18a0) QQmlContext(0x55c06d7f8570) QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")

(In reply to marav from comment #21)
> (In reply to Nathan from comment #20)
> > I have been hitting this bug constantly on 5.26.2
> 
> Same here, plasma 5.26.2
> 
> org.kde.plasma.libtaskmanager: Got invalid activation app_id: ""
> Service  ":1.130" unregistered
> kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x1a8d760)
> kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x1a8d760)
> kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x1a8d760)
> kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x1a8d760)
> message too short, object (313), message set_app_id(s)
> error in client communication (pid 1485)
> wl_display@1: error 1: invalid arguments for
> xdg_activation_token_v1@313.set_app_id
> The Wayland connection experienced a fatal error: Argument invalide
> Service  "org.kde.StatusNotifierHost-1485" unregistered

That's a completely different protocol error

*** Bug 461397 has been marked as a duplicate of this bug. ***

From https://bugs.kde.org/show_bug.cgi?id=461397:

[4245733.460] wl_display@1.error(wl_display@1, 1, "invalid arguments for org_kde_plasma_surface@270.set_output")
wl_display@1: error 1: invalid arguments for org_kde_plasma_surface@270.set_output
The Wayland connection experienced a fatal error: Invalid argument

So we have at least four somewhat different protocol errors

(In reply to Nicolas Fella from comment #23)
> (In reply to marav from comment #21)
> > (In reply to Nathan from comment #20)
> > > I have been hitting this bug constantly on 5.26.2
> > 
> > Same here, plasma 5.26.2
> > 
> > org.kde.plasma.libtaskmanager: Got invalid activation app_id: ""
> > Service  ":1.130" unregistered
> > kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x1a8d760)
> > kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x1a8d760)
> > kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x1a8d760)
> > kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x1a8d760)
> > message too short, object (313), message set_app_id(s)
> > error in client communication (pid 1485)
> > wl_display@1: error 1: invalid arguments for
> > xdg_activation_token_v1@313.set_app_id
> > The Wayland connection experienced a fatal error: Argument invalide
> > Service  "org.kde.StatusNotifierHost-1485" unregistered
> 
> That's a completely different protocol error

Indeed
By "same",  I meant "same user exeperience" not really "same issue"

(In reply to Nicolas Fella from comment #25)
> From https://bugs.kde.org/show_bug.cgi?id=461397:
> 
> [4245733.460] wl_display@1.error(wl_display@1, 1, "invalid arguments for
> org_kde_plasma_surface@270.set_output")
> wl_display@1: error 1: invalid arguments for
> org_kde_plasma_surface@270.set_output
> The Wayland connection experienced a fatal error: Invalid argument
> 
> So we have at least four somewhat different protocol errors

Given that the crash can happen just by moving the cursor over the task manager icons so that their tooltips were shown and the errors, a race condition could've been involved in which the Wayland objects/surfaces of the icons' tooltips might occasionally have been freed while still in use or not. The following errors I reported at https://bugs.kde.org/show_bug.cgi?id=461397 might've been the next uses of the Wayland objects/surfaces of the icons' tooltips after they were freed.
wl_display@1: error 1: invalid arguments for org_kde_plasma_surface@270.set_output
kwin_wayland_wrapper[1652]: invalid object (256), type (wl_buffer), message set_region(?o)
plasmashell[3304]: wl_display@1: error 1: invalid method 1, object wl_buffer@226

Created attachment 153472 [details]
valgrind log of running plasmashell --replace

I reproduced this type of plasmashell crash twice while running it under valgrind like valgrind --log-file=valgrind-plasmashell-task-manager-icons-2.txt --enable-debuginfod=no plasmashell --replace (in konsole) in a Fedora Rawhide KDE Plasma live image in GNOME Boxes QEMU/KVM VM with Plasma 5.26.2, KF 5.26.2, Qt 5.15.7. I started Firefox and Konsole then moved the cursor back and forth over the task manager icons so that tooltips were shown until the crash happened. The first plasmashell shell had the errors 
kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x23cd7220)
wl_display@1: error 1: invalid arguments for org_kde_plasma_surface@157.set_output
The Wayland connection experienced a fatal error: Invalid argument

The second plasmashell crash had the errors 
org.kde.kf5.kwindowsystem.kwayland: Failed to recreate shadow for ToolTipDialog(0x24271af0)
wl_display@1: error 0: invalid object 204
The Wayland connection experienced a fatal error: Invalid argument
The Wayland connection experienced a fatal error: Invalid argument

The valgrind logs showed 26 and 11 invalid reads of 16 bytes which were less than 16 bytes from the end of the buffers, and so they might've been overreads. The stacks of the allocations had functions which seemed to be involved with SVG rendering. The stacks of where the invalid reads were just showed ??s so they're difficult to interpret. The first such invalid read from the second crash's run was

==3516== Invalid read of size 16
==3516==    at 0x25B21A90: ???
==3516==    by 0x23DAB237: ???
==3516==  Address 0x23dabf2e is 3,342 bytes inside a block of size 3,352 alloc'd
==3516==    at 0x484186F: malloc (vg_replace_malloc.c:393)
==3516==    by 0x696F581: QArrayData::allocate(unsigned long, unsigned long, unsigned long, QFlags<QArrayData::AllocationOption>) (qarraydata.cpp:218)
==3516==    by 0x69F125D: allocate (qarraydata.h:225)
==3516==    by 0x69F125D: QString::fromLatin1_helper(char const*, int) (qstring.cpp:5464)
==3516==    by 0x4B44999: UnknownInlinedFun (qstring.h:701)
==3516==    by 0x4B44999: UnknownInlinedFun (qstring.h:713)
==3516==    by 0x4B44999: Plasma::SharedSvgRenderer::load(QByteArray const&, QString const&, QHash<QString, QRectF>&) [clone .isra.0] (svg.cpp:134)
==3516==    by 0x4B320B3: UnknownInlinedFun (svg.cpp:81)
==3516==    by 0x4B320B3: Plasma::SvgPrivate::createRenderer() [clone .part.0] (svg.cpp:681)
==3516==    by 0x4B23617: UnknownInlinedFun (qbasicatomic.h:118)
==3516==    by 0x4B23617: UnknownInlinedFun (svg.cpp:756)
==3516==    by 0x4B23617: Plasma::SvgPrivate::elementRect(QString const&) (svg.cpp:745)
==3516==    by 0x4B248C3: Plasma::SvgPrivate::checkColorHints() (svg.cpp:777)
==3516==    by 0x4B25C8E: Plasma::SvgPrivate::setImagePath(QString const&) (svg.cpp:511)
==3516==    by 0x4B27600: Plasma::Svg::setImagePath(QString const&) (svg.cpp:1108)
==3516==    by 0x27BFA030: UnknownInlinedFun (iconitem.cpp:186)
==3516==    by 0x27BFA030: IconItem::setSource(QVariant const&) (iconitem.cpp:370)
==3516==    by 0x56B3701: QQmlPropertyPrivate::write(QObject*, QQmlPropertyData const&, QVariant const&, QQmlContextData*, QFlags<QQmlPropertyData::WriteFlag>) (in /usr/lib64/libQt5Qml.so.5.15.7)
==3516==    by 0x571AEFB: QQmlBinding::slowWrite(QQmlPropertyData const&, QQmlPropertyData const&, QV4::Value const&, bool, QFlags<QQmlPropertyData::WriteFlag>) (in /usr/lib64/libQt5Qml.so.5.15.7)
==3516== 

There were also many Conditional jump or move depends on uninitialised value(s) lines which could've contributed to the problem. I'm attaching the valgrind log for the second crash's run.

@Matt Fagnani can you reproduce the crash if the blur effect is disabled?

Can you also run plasmashell with the WAYLAND_DEBUG=1 environment variable and post the log after plasmashell crashes?

Created attachment 153508 [details]
valgrind log of running plasmashell --replace with Blur effect disabled

Vlad, I reproduced three plasmashell crashes after disabling the Blur effect in System Settings in Plasma 5.26.2 on Wayland, with KF 5.99.0, Qt 5.15.7 in a Fedora Rawhide KDE Plasma live image Fedora-KDE-Live-x86_64-Rawhide-20221103.n.0.iso on bare metal. The second crash happened the first time I moved the cursor over the Firefox task manager icon. The third crash was when I was running plasmashell under valgrind and took a minute of moving the cursor over the task manager icons. It had errors like 
kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x38aa6070)
wl_display@1: error 0: invalid object 145
The Wayland connection experienced a fatal error: Invalid argument

The same sorts of invalid reads were shown in the attached valgrind log. The invalid reads might be enough to lead to the invalid object errors from kwin_wayland, or they might result in memory corruption leading to the crashes.

I attached a WAYLAND_DEBUG=1 plasmashell --replace log for a previous crash at https://bugs.kde.org/show_bug.cgi?id=461397#c1 though that one only had the last 1000 lines or so due to the default konsole line limit. I could make a full one if you want.

> I attached a WAYLAND_DEBUG=1 plasmashell --replace log for a previous crash at https://bugs.kde.org/show_bug.cgi?id=461397#c1 though that one only had the last 1000 lines or so due to the default konsole line limit. I could make a full one if you want.

Yes please. FTR I redirect stderr and stdout to a file.

Another thing that's worth testing is whether the crash is reproducible with the basic QSG render loop, I suspect that there might be some race condition in QPA. You can set the basic render loop in plasma renderer kcm, e.g. open "krunner" and type "plasma renderer", then select "basic" render loop, and restart plasmashell process.

Created attachment 153561 [details]
WAYLAND_DEBUG=1 plasmashell --replace output when plasmashell crashed with wl_proxy_unref: Assertion `proxy->refcount > 0' failed.

I reproduced the crash in Plasma 5.26.2 in a Fedora Rawhide live image with KF 5.99.0 and Qt 5.15.7 and the blur effect disabled using WAYLAND_DEBUG=1 plasmashell --replace > /tmp/plasmashell/plasmashell-wayland-debug-1.txt 2> /tmp/plasmashell/plasmashell-wayland-debug-1.txt, but the errors weren't shown in the log and the log was 50 MB. A second crash with just WAYLAND_DEBUG=1 plasmashell --replace showed a failed assertion plasmashell: ../src/wayland-client.c:230: wl_proxy_unref: Assertion `proxy->refcount > 0' failed. I'm attaching what I could copy from konsole of the Wayland debug log before the second crash. The drkonqi notification disappeared before I clicked on it and the crash wasn't shown in the Crashed Processes Viewer or coredumpctl so I didn't get the trace. I saw a plasmashell crash in wl_proxy_unref yesterday when I reproduced this problem which had a trace like that reported at https://bugs.kde.org/show_bug.cgi?id=452370 drkonqi crashed after I installed the debuginfo packages for libwayland-client qt5-qtbase etc. and clicked Reload in it so I don't have the trace. The failed assertion might've indicated that the Wayland proxy had been freed and then was being used or freed again. I'll try with the basic Renderer loop as suggested and see what happens.  Thanks

A possibly relevant merge request was started @ https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/57

*** Bug 460575 has been marked as a duplicate of this bug. ***

*** Bug 451319 has been marked as a duplicate of this bug. ***

*** Bug 461429 has been marked as a duplicate of this bug. ***

*** Bug 461600 has been marked as a duplicate of this bug. ***

*** Bug 449351 has been marked as a duplicate of this bug. ***

*** Bug 461643 has been marked as a duplicate of this bug. ***

Note that I experienced the issue on Xorg, not Wayland.

Fixed in the Qt patch collection.

Reopening because the qt patch was reverted.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-integration/-/merge_requests/59

(In reply to Vlad Zahorodnii from comment #32)
> > I attached a WAYLAND_DEBUG=1 plasmashell --replace log for a previous crash at https://bugs.kde.org/show_bug.cgi?id=461397#c1 though that one only had the last 1000 lines or so due to the default konsole line limit. I could make a full one if you want.
> 
> Yes please. FTR I redirect stderr and stdout to a file.
> 
> Another thing that's worth testing is whether the crash is reproducible with
> the basic QSG render loop, I suspect that there might be some race condition
> in QPA. You can set the basic render loop in plasma renderer kcm, e.g. open
> "krunner" and type "plasma renderer", then select "basic" render loop, and
> restart plasmashell process.

I tried to reproduce the crash for about 20 minutes in total after setting the basic render loop, but I didn't see the crash happen. Since the crash usually happened after a second to a few minutes when I was moving the cursor over the task manager icons, plasmashell using the basic render loop might not be affected by this problem. The problem and patch as described at https://invent.kde.org/plasma/plasma-integration/-/merge_requests/59 make sense to me. Thanks.

I have also enabled basic render loop and I have not seen the issue all day

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2332

Hi, I also get these crashes a lot. I updated to Plasma 5.26.3 yesterday and they still happen frequently.

I set the render loop to "basic" which seems to stop these crashes.
Now however, after some time icon-only-taskbar freezes instead of producing a crash. This happens in the same situations that would normally trigger a crash (hovering over taskbar icons or launching an application). Icon-only-taskbar is the only widget that freezes, all other panel widgets continue to work fine and I'm still able to switch between windows via Alt-Tab.

Git commit 9c998d3083f622a1677782248d4c8e238c935dc2 by Arjen Hiemstra.
Committed on 18/11/2022 at 14:05.
Pushed by ahiemstra into branch 'master'.

shell: Use the basic scene graph rendering loop on wayland

This avoids crashing Plasma when a surface gets destroyed too early
while still in use by the threaded loop. To avoid leaking things into
child processes, we clear the environment variable again after we've
created the initial views for the shell.

M  +20   -0    shell/main.cpp
M  +2    -0    shell/shellcorona.cpp
M  +1    -0    shell/shellcorona.h

https://invent.kde.org/plasma/plasma-workspace/commit/9c998d3083f622a1677782248d4c8e238c935dc2

Git commit 0fff87982b7164a442b549509fa9fa792007880a by Arjen Hiemstra.
Committed on 18/11/2022 at 15:00.
Pushed by ahiemstra into branch 'cherry-pick-9c998d30'.

shell: Use the basic scene graph rendering loop on wayland

This avoids crashing Plasma when a surface gets destroyed too early
while still in use by the threaded loop. To avoid leaking things into
child processes, we clear the environment variable again after we've
created the initial views for the shell.


(cherry picked from commit 9c998d3083f622a1677782248d4c8e238c935dc2)

M  +20   -0    shell/main.cpp
M  +2    -0    shell/shellcorona.cpp
M  +1    -0    shell/shellcorona.h

https://invent.kde.org/plasma/plasma-workspace/commit/0fff87982b7164a442b549509fa9fa792007880a

I wonder if this is the same issue:
https://bugs.kde.org/show_bug.cgi?id=461782

There are significant differences in the observed behavior, but also similarities...

That fix was reverted; re-opening.

...and closing again because the Qt patch that fixes it was backported to the KDE Qt patch collection; see https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/57.

(In reply to Nate Graham from comment #53)
> ...and closing again because the Qt patch that fixes it was backported to
> the KDE Qt patch collection; see
> https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/57.
No, that got reverted.

https://invent.kde.org/qt/qt/qtwayland/-/commit/4b43f2dc58e71732ebdbe1eaf4392272bc692e6d

Well darn. :(

At least the fix is in Qt 6.3, so I guess the worst-case scenatio is that this is a Plasma 6 fix.

*** Bug 462400 has been marked as a duplicate of this bug. ***

*** Bug 462161 has been marked as a duplicate of this bug. ***

Do we know why the fixes were reverted?
I'm guessing that they either caused other severe issues or actually didn't fix the root problem?

I would be very sad if we have to wait for Plasma 6 for this to be fixed.
But of course I understand that this might be a very hard problem to fix.

To clarify:
 - The situation in Qt6 is not reverted and should work well
 - It relies on new API that QtDeclarative then uses. Our backports can't include new API  
 - The attempt above hooked into "makeCurrent" "doneCurent" 
 - That simply didn't work, makeCurrent isn't called every frame as on that thread we don't have to make it current again
 - It hit complete deadlocks, we need to be careful when it comes to mutexes

*** Bug 461601 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2410

Git commit c97448ebe5987acd08da9475733f92931c074b95 by Vlad Zahorodnii.
Committed on 06/12/2022 at 20:49.
Pushed by vladz into branch 'master'.

Revert "shell: Use the basic scene graph rendering loop on wayland"

This reverts commit 9c998d3083f622a1677782248d4c8e238c935dc2.

There are two issues with basic render loop on Wayland:

* Same OpenGL context is reused across windows with incompatible
  EGLConfigs. It results in QOpenGLContext::makeCurrent() failing for
  some windows. At quick glance, it seems to be fixed with RHI
* QQuickWindowPrivate::flushFrameSynchronousEvents() can be called by
  QSGRenderLoop in the middle of painting after making opengl context
  current. That, by itself, is a source of undefined behavior
  because current opengl context can be different after
  QQuickWindowPrivate::flushFrameSynchronousEvents() is called. This can
  result in eglSwapBuffers() failing due to wrong read & draw surfaces
  and QtWayland ending in a broken state.

The first issue should be fixed by just upgrading to Qt 6. The second
issue needs to be fixed.

Unfortunately, it affects the stability of plasmashell. There are
threading issues in QtWayland that cannot be fixed without changing
qtdeclarative and qtbase. With this, plasmashell will use threaded
renderer and hit those threading issues again.

M  +0    -20   shell/main.cpp
M  +0    -2    shell/shellcorona.cpp
M  +0    -1    shell/shellcorona.h

https://invent.kde.org/plasma/plasma-workspace/commit/c97448ebe5987acd08da9475733f92931c074b95

*** Bug 463163 has been marked as a duplicate of this bug. ***

I have done about 3 fresh installs lately on different machines and hit this bug within minutes. So all of them have been switched to basic render loop which I know is not ideal but its better than constantly having this crash.

(In reply to Nate Graham from comment #55)
> Well darn. :(
> 
> At least the fix is in Qt 6.3, so I guess the worst-case scenatio is that
> this is a Plasma 6 fix.

Which, for an end user, means WHEN?

Looks like again we will be falling victim to the bad policy, "if there is a fix upstream, do nothing, even if the fix is MONTHS up stream".

(In reply to Szczepan Hołyszewski from comment #65)
> (In reply to Nate Graham from comment #55)
> > Well darn. :(
> > 
> > At least the fix is in Qt 6.3, so I guess the worst-case scenatio is that
> > this is a Plasma 6 fix.
> 
> Which, for an end user, means WHEN?
8-12 months from now, when Plasma 6 is released.

> Looks like again we will be falling victim to the bad policy, "if there is a
> fix upstream, do nothing, even if the fix is MONTHS up stream".
As you can see from Comment 49 and follow-up comments, we did try to work around this in Plasma code. Unfortunately the workaround caused other issues. We also tried to backport the Qt 6 fix fix to Qt 5, and that caused regressions too. Do you have an idea of what else we could have done to improve this for the Plasma 5 series?

> 8-12 months from now, when Plasma 6 is released.

> As you can see from Comment 49 and follow-up comments, we did try to work around this in Plasma code

So you have a 8-12 month margin, and you already give up?

I'm just explaining how it is. If you have an idea for how to fix it in Qt 5 without causing regressions, we're all ears.

It's been 3 or 4 years now since I came back to Plasma (IIRC 5.15)
I spent 2 years on x11/wayland and now +/- 6 months on a full wayland/wayland session.
All I can say is: congratulations to you guys at KDE for all the good (hard?) work you have done in the last years.

We all know that this is a transition period to qt6 and that not everything will be perfect. 
Everyone must try to contribute in a constructive way

Side note: I know it's a bug tracker, but some thanks, it's always good to take ;-)

I do agree its a bad bug, having the desktop crash on you isnt a good feeling/look, but if there no answer at least setting render loop to basic does seem to fix it. It may create other issues but I have had it this way since Nov when that was suggested and I have not hit any major issues since,so atm it seems the best solution??

I've been running into several crashes a day do to this bug and it was honestly driving me crazy.  I finally stumbled across this bug report (and the fix to set "Render Loop" to "Basic" is via the "Plasma Renderer" utility).

Given that it will be a while before it's fully fixed (it's fixed in upstream Qt, but plasma will need to be migrated to Qt 6+), perhaps it might be possible to have the "Automatic" setting for Render Loop detect if plasma is running using wayland and if it is, set the Render Loop to "Basic" behind the scenes?

I think this will prevent a huge amount of user frustration.

Apologies, please disregard my previous message.  I didn't read the thread closely enough.  I see now that the original attempt to fix the issue was exactly what I had suggested, and then it was reverted for legitimate reasons.

*** Bug 464797 has been marked as a duplicate of this bug. ***

*** Bug 463985 has been marked as a duplicate of this bug. ***

I've been thinking about this issue and how it affects the perception of Plasma's stability (specifically with the upcoming 5.27 release).

I *do* understand that there are challenges with defaulting the Render Loop to "Basic" when running under a Wayland session, and this approach comes with it's own potential issues.  But, the alternative is having plasma crash multiple times a day when using the taskbar.  The number of duplicate bug reports related to this speak to how common this issue is.

As someone that has been running with Render Loop set to "Basic" for the past couple of weeks with zero noticeable problems I think this would certainly be preferable.  @nate has also mentioned that he is running with the same configuration with no know issues.

I suppose when faced with two less than ideal choices, shouldn't the choice that causes least amount of crashes and side effects be the one that's chosen?

The reason I bring this up again was that until I discovered this bug report, I was getting consistent daily crashes with plasma.  It was to the point that I was starting to consider switching to another DE.  After discovering this bug report, and setting the Render Loop to Basic the problems have been resolved for me.  This is fine for me, but I think we would all agree it's a terrible user experience to rely on users discovering the bug report, parsing through the messages, and solving it manually right?

Unfortunately Basic Render Loop does cause issues. I have noticed that slowly icons on the taskbar become unresponsive until I had only the menu working. To be fair it does not happen all the time but I have struck it several times now. I think the bigger question is when did this bug first occur? I have been using Plasma for years without this problem but I cannot say for definite when I first noticed it ( I do remember this is 5.25 but was it there in 5.24) and what changed to cause it. Is the the previews? I which case I am happy to be without them and have a stable desktop. It is getting the point where I am starting to wonder if I should be running Plasma in production environments as it either crashes or freezes neither option ideal. This really should be on the high priority bug list as it is getting reported more and more.

I think the bug has been mitigated in 5.27.0 due to some changes in the task manager's tooltip.

Today I put the render loop back to automatic and disabled tooltips to see if it would help, so I am happy to hear that maybe I was on the right track be interesting to see if that helps

(In reply to Fushan Wen from comment #77)
> I think the bug has been mitigated in 5.27.0 due to some changes in the task
> manager's tooltip.

Nope, 5.27.0 here and writing this without plasmashell running because it crashed when I hovered over the panel.

Yes I have had it happen twice this morning on 5.27.0 but the error is different from before 

systemd[1724]: Started plasma-plasmashell.service - KDE Plasma Workspace.
systemd[1724]: Starting plasma-plasmashell.service - KDE Plasma Workspace...
systemd[1724]: plasma-plasmashell.service: Consumed 9.890s CPU time.
systemd[1724]: Stopped plasma-plasmashell.service - KDE Plasma Workspace.
systemd[1724]: plasma-plasmashell.service: Scheduled restart job, restart counter is at 1.
systemd[1724]: plasma-plasmashell.service: Consumed 9.890s CPU time.
systemd[1724]: plasma-plasmashell.service: Failed with result 'exit-code'.
systemd[1724]: plasma-plasmashell.service: Main process exited, code=exited, status=1/FAILURE
plasmashell[2099]: The Wayland connection experienced a fatal error: Invalid argument
plasmashell[2099]: wl_display@1: error 0: invalid object 201
kwin_wayland_wrapper[1827]: error in client communication (pid 2099)
plasmashell[2099]: file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:286: Unable to assign [undefined] to QString

*** Bug 464933 has been marked as a duplicate of this bug. ***

*** Bug 466371 has been marked as a duplicate of this bug. ***

*** Bug 467069 has been marked as a duplicate of this bug. ***

*** Bug 461600 has been marked as a duplicate of this bug. ***