SUMMARY I don't have a good way to reproduce this, happens every few minutes. It can be triggered by starting any app, or closing an app. SOFTWARE/OS VERSIONS KDE Frameworks Version: 5.82 Qt Version: 5.15.2+kde+r192-1 ADDITIONAL INFORMATION One of the logs: https://pastebin.com/GrvYZxC7
I also looked at the rest of the logs, they seem to be the same.
Some actions that trigger this crash: neofetch - right before listing present gpus chromium - right after start vlc - when a (video) file is opened anything with DRI_PRIME=1 -- Everything seems to be GPU related or multi-gpu related I am guessing Plasma does something wrong with the driver and it crashes or something like that? -- Although the crash always looks the same it's not always assigned(?) to the same process, see the output from my 'coredumpctl info': https://pastebin.com/j3Ug5at3
Anyone else on AMD RAVEN (or RENOIR, or anything AMD) have the same issue? Mesa version is 21.1.0
(In reply to Matej Mrenica from comment #3) > Anyone else on AMD RAVEN (or RENOIR, or anything AMD) have the same issue? > Mesa version is 21.1.0 I'm having applications crash randomly, but it's not happening with anything you listed. Might be a PRIME thing since you're apparently using that? Plasma 5.22 Beta, same with 5.21 (on Wayland) KDE Frameworks 5.82.0 Qt 5.15.2 GPU RX Vega 64
(In reply to Marco Rebhan from comment #4) > (In reply to Matej Mrenica from comment #3) > > Anyone else on AMD RAVEN (or RENOIR, or anything AMD) have the same issue? > > Mesa version is 21.1.0 > > I'm having applications crash randomly, but it's not happening with anything > you listed. Might be a PRIME thing since you're apparently using that? > > Plasma 5.22 Beta, same with 5.21 (on Wayland) > KDE Frameworks 5.82.0 > Qt 5.15.2 > GPU RX Vega 64 But I am not using PRIME with anything mentioned above. I just meant that every other app that doesn't cause the crash, does that if DRI_PRIME is set.
Killing all running apps when it crashes is known and being worked on. The problem is KWin crashing in the first place. Can you get a backtrace? Run `coredumpctl debug kwin_wayland` and then type `bt` when you get a prompt. See also https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl
I've rebuilt kwin, plasma-desktop and plasma-workspace with debug enabled. One of the logs: https://pastebin.com/TvfrQgZY All of them end with: "KWin::GLVertexBuffer::reset() () from /usr/lib/libkwinglutils.so.13"
There are also coredumps from other apps (like plasmashell, xembedsniproxy and gmenudbusmenuproxy), but I am assuming they are only crashing because of kwin, right?
(In reply to Nate Graham from comment #6) > Killing all running apps when it crashes is known and being worked on. The > problem is KWin crashing in the first place. Can you get a backtrace? Run > `coredumpctl debug kwin_wayland` and then type `bt` when you get a prompt. > > See also > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl Yes, this report is meant to be about kwin crashing not apps being killed.
Thanks! #0 0x00007f224d6c46e8 in KWin::GLVertexBuffer::reset() () at /usr/lib/libkwinglutils.so.13 #1 0x00007f2244221fcc in KWin::SceneOpenGL2::doPaintBackground(QVector<float> const&) () at /usr/lib/qt/plugins/org.kde.kwin.scenes/KWinSceneOpenGL.so #2 0x00007f22442271a3 in KWin::SceneOpenGL::paintBackground(QRegion const&) () at /usr/lib/qt/plugins/org.kde.kwin.scenes/KWinSceneOpenGL.so #3 0x00007f224da663b0 in KWin::Scene::paintSimpleScreen(int, QRegion const&) () at /usr/lib/libkwin.so.5 #4 0x00007f224da60b76 in KWin::Scene::finalPaintScreen(int, QRegion const&, KWin::ScreenPaintData&) () at /usr/lib/libkwin.so.5 #5 0x00007f224d9c7a44 in KWin::EffectsHandlerImpl::paintScreen(int, QRegion const&, KWin::ScreenPaintData&) () at /usr/lib/libkwin.so.5 #6 0x00007f224da6778f in KWin::Scene::paintScreen(int*, QRegion const&, QRegion const&, QRegion*, QRegion*, KWin::RenderLoop*, QMatrix4x4 const&) () at /usr/lib/libkwin.so.5 #7 0x00007f224422827b in KWin::SceneOpenGL::paint(int, QRegion const&, QList<KWin::Toplevel*> const&, KWin::RenderLoop*) () at /usr/lib/qt/plugins/org.kde.kwin.scenes/KWinSceneOpenGL.so #8 0x00007f224d98d4da in KWin::Compositor::composite(KWin::RenderLoop*) () at /usr/lib/libkwin.so.5 #9 0x00007f224c047b76 in () at /usr/lib/libQt5Core.so.5 #10 0x00007f224d938113 in KWin::RenderLoop::frameRequested(KWin::RenderLoop*) () at /usr/lib/libkwin.so.5 #11 0x00007f224da51c74 in KWin::RenderLoopPrivate::dispatch() () at /usr/lib/libkwin.so.5 #12 0x00007f224c047b76 in () at /usr/lib/libQt5Core.so.5 #13 0x00007f224c04bc0b in QTimer::timeout(QTimer::QPrivateSignal) () at /usr/lib/libQt5Core.so.5 #14 0x00007f224c03d25f in QObject::event(QEvent*) () at /usr/lib/libQt5Core.so.5 #15 0x00007f224ce50762 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5 #16 0x00007f224c01081a in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5 #17 0x00007f224c0686a5 in QTimerInfoList::activateTimers() () at /usr/lib/libQt5Core.so.5 #18 0x00007f224c066b29 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #19 0x000055897b833c1e in QUnixEventDispatcherQPA::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () #20 0x00007f224c00f17c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/libQt5Core.so.5 #21 0x00007f224c017634 in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5 #22 0x000055897b7d5172 in main ()
After demangling my core dump with c++filt it seems to provide the same backtrace Nate posted on comment #10. This seems to be hindering login to the Wayland session with latest KWin from master, causing multiple sequential crashes according to journalctl (I tested with a new user as well). I'm on openSUSE Krypton.
The crash on login is fixed by https://invent.kde.org/plasma/kwin/-/merge_requests/1063. It only affected git master though, so the original issue is likely still there.
This seems to be fixed since 5.22.0, can anyone confirm?
> This seems to be fixed since 5.22.0, can anyone confirm? Can confirm, I don't think I've encountered this in a while since updating to 5.22.
Closing per above comments.