Bug 413351

Summary: Wayland session freezes computer on Nouveau works fine on proprietary Nvidia drivers
Product: [Plasma] kwin Reporter: alggwp
Component: generalAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED WORKSFORME    
Severity: crash CC: kde
Priority: NOR    
Version: 5.17.1   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description alggwp 2019-10-23 07:26:55 UTC
Starting Wayland session crashes the entire computer. Only way to regain control is to force shutdown it through SysRq magic. Killing through Sysrq doesn't evne work only force shutting down. Sometimes it happens as soon as the splash screen is shown sometimes after I restart latte-dock (if the session does not crash on start latte will crash after couple seconds), sometimes if I right click on the desktop it crashes. I can't pinpoint it but I am +60% confident it is caused by plasmashell (or something related) since starting kwin_wayland alone does not produce the crash. And yes I added a new user and tried it with it and same result. 

STEPS TO REPRODUCE
1. Start a wayland session
2. If it doesn't instantly crash play around the desktop couple seconds
3. Crash


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Upstream Arch on KDE-Unstable (kernel 5.3.7)
KDE Plasma Version:  5.17.1
KDE Frameworks Version: 5.63.0
Qt Version: 5.14

I am on nouveau driver. Last time I tried the nvidia proprietary driver does NOT crash at all under wayland (but there is no xwayland so it's useless). Disabling ksplashqml seems to avoid the crash for a couple of seconds. Maybe it's placebo I don't know but when the Splash screen is enabled it will usually instantly crash at the KDE logo while without splash screen it will work couple seconds (10-20secs) like mentioned before crashing
Comment 1 alggwp 2019-10-23 23:22:25 UTC
Wayland session does not crash with proprietary nvidia drivers literally just tried it out.
Comment 2 alggwp 2019-10-30 19:57:02 UTC
Ok so appearently this is caused by every QT based application at some point. Had an update today for Arch and it made it clear. If Latte-Dock (which did NOT get an update today) is in autostart the session will freeze. Similarly if I try to open the desktop background selection of plasmashell it will freeze the same way.

There is some underlying problem that needs to be fixed.
Comment 3 alggwp 2019-11-01 00:25:09 UTC
Starting all those QT apps with QT_QPA_PLATFORM=xcb prevents the crash which in turn defeats the purpose of Wayland though. The only appliction where it works fine is Konsole (and Kwin obviously).
Comment 4 Vlad Zahorodnii 2019-11-21 14:18:51 UTC
> Starting Wayland session crashes the entire computer.
Please attach a backtrace to this bug report.

https://community.kde.org/KWin/Debugging
Comment 5 alggwp 2019-11-26 05:29:19 UTC
Hello,

so during the last weeks there was some movement. Kwin and Plasma work fine but it is Qt that is at fault. Every Qt app, if run as QT_QPA_PLATFORM=wayland, will crash the entire computer after a while with having to reboot (cant switch ttys). Same happens under Sway, Weston and Plasma. Plasma has the misfortune (in this case) that it itself is Qt based. Whether it's plasmashell, systemsettings5, qutebrowser, wireshark or some self compiled 5 line hello world after a while any one of them will crash the entire computer. Even a Qt app run with QPA_PLATFORM=wayland under Weston inside an X session will crash the entire computer.

Also strange is that konsole apparently doesn't crash anything. It is the only Qt application that doesn't seem to have a problem.

This evidently is a Qt bug not a Plasma bug so I think this should rather be reported at Qts issue tracker. I'll do so when I get access to the machine again and get a backtrace of it.
Comment 6 Bug Janitor Service 2019-12-11 04:33:07 UTC
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!
Comment 7 Vlad Zahorodnii 2019-12-13 16:20:28 UTC
Okay that's good to know.
Comment 8 Bug Janitor Service 2019-12-28 04:33:06 UTC
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!
Comment 9 Bug Janitor Service 2020-01-12 04:33:10 UTC
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!