Created attachment 155643 [details] dump with debug symbols This is a follow-up from bug 464794 Since I upgraded to 5.27 beta on Arch I have been getting frequent plasma crashes. There doesn't seem to be any correlation between them on anything I do in particular. I have attached a full dump with debug symbols. title to be updated once more is known about the nature of the crash.
Operating System: Arch Linux KDE Plasma Version: 5.26.90 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 Kernel Version: 6.1.8-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 6800 XT
Sig 6 after #12 0x00007fc34b322bd9 in QtWaylandClient::EventThread::readAndDispatchEvents() (this=<optimized out>) at /usr/src/debug/qt5-wayland/qtwayland/src/client/qwaylanddisplay.cpp:155
just casting a wide net here..but is anyone else experiencing frequent crashes on Wayland since Plasma 5.27 beta released? It feels like I am getting at least a few each day and would be getting even more if I wasn't working (inside a VM) but using the desktop instead: Thu 2023-01-26 20:47:27 CET 10910 1000 1000 SIGABRT present /usr/bin/plasmashell 24.7M Thu 2023-01-26 20:26:56 CET 7913 1000 1000 SIGABRT present /usr/bin/plasmashell 24.2M Thu 2023-01-26 19:54:47 CET 1888 1000 1000 SIGABRT present /usr/bin/plasmashell 24.2M Thu 2023-01-26 13:55:23 CET 20173 1000 1000 SIGABRT present /usr/bin/plasmashell 25.6M Thu 2023-01-26 13:00:59 CET 9607 1000 1000 SIGABRT present /usr/bin/plasmashell 28.1M Thu 2023-01-26 09:39:00 CET 1894 1000 1000 SIGABRT present /usr/bin/plasmashell 24.7M I will check the core dumps to see if they are in the same place and open bugs for each unique one.
It's not technically a crash, it's being killed by wayland for doing something deemed incorrect. Can I have output of journalctl --user -u plasma-plasmashell.service -b after this issue
Created attachment 155687 [details] journalctl --user -u plasma-plasmashell.service -b sure, here you go.
*** Bug 464878 has been marked as a duplicate of this bug. ***
Looks relevant: Jan 26 19:54:44 arch-Bednar plasmashell[1888]: QBuffer::writeData: Memory allocation error Jan 26 19:54:44 arch-Bednar plasmashell[1888]: libpng error: Write Error Jan 26 19:54:44 arch-Bednar plasmashell[1888]: Qt Concurrent has caught an exception thrown from a worker thread. This is not supported, exceptions thrown in worker threads must be caught before control returns to Qt Concurrent. Jan 26 19:54:44 arch-Bednar plasmashell[1888]: terminate called after throwing an instance of 'std::bad_alloc' Jan 26 19:54:44 arch-Bednar plasmashell[1888]: what(): std::bad_alloc Jan 26 19:54:44 arch-Bednar plasmashell[1888]: 25 -- exe=/usr/bin/plasmashell
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2608
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2609
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2612
Git commit 4649594aa95d601ac6449c9e8baf8201b28602c5 by Fushan Wen. Committed on 12/02/2023 at 15:38. Pushed by fusionfuture into branch 'master'. klipper: store QImage and construct QPixmap only when necessary The mime data from Wayland clipboard is not the exact same image, so two image items are listed (first time restarting plasmashell). But after images are saved to local, they have the same uuid again. So klipper starts to become confused after the second time restarting plasmashell. This is caused by QPixmap::from(QImage).toImage() erasing metadata in the image, and KSystemClipboard will emit changed signal on Wayland, so another identical image is added to clipboard. Related: bug 465225, bug 465326, bug 465603 FIXED-IN: 5.27 M +5 -5 klipper/historyimageitem.cpp M +2 -2 klipper/historyimageitem.h M +3 -4 klipper/historyitem.h https://invent.kde.org/plasma/plasma-workspace/commit/4649594aa95d601ac6449c9e8baf8201b28602c5
Git commit 41ac399c39a653cac1d63b3f1913ed4eb2f0d2c3 by Fushan Wen. Committed on 13/02/2023 at 00:29. Pushed by fusionfuture into branch 'cherry-pick-4649594a'. klipper: store QImage and construct QPixmap only when necessary The mime data from Wayland clipboard is not the exact same image, so two image items are listed (first time restarting plasmashell). But after images are saved to local, they have the same uuid again. So klipper starts to become confused after the second time restarting plasmashell. This is caused by QPixmap::from(QImage).toImage() erasing metadata in the image, and KSystemClipboard will emit changed signal on Wayland, so another identical image is added to clipboard. Related: bug 465225, bug 465326, bug 465603 FIXED-IN: 5.27 (cherry picked from commit 4649594aa95d601ac6449c9e8baf8201b28602c5) M +5 -5 klipper/historyimageitem.cpp M +2 -2 klipper/historyimageitem.h M +3 -4 klipper/historyitem.h https://invent.kde.org/plasma/plasma-workspace/commit/41ac399c39a653cac1d63b3f1913ed4eb2f0d2c3
Git commit 89d1f0e07955427a083cbc5af34e0ae9fdcdaad4 by Fushan Wen. Committed on 13/02/2023 at 00:46. Pushed by fusionfuture into branch 'Plasma/5.27'. klipper: store QImage and construct QPixmap only when necessary The mime data from Wayland clipboard is not the exact same image, so two image items are listed (first time restarting plasmashell). But after images are saved to local, they have the same uuid again. So klipper starts to become confused after the second time restarting plasmashell. This is caused by QPixmap::from(QImage).toImage() erasing metadata in the image, and Wayland clipboard is async, so another identical image is added to clipboard. Related: bug 465225, bug 465326, bug 465603 FIXED-IN: 5.27 (cherry picked from commit 4649594aa95d601ac6449c9e8baf8201b28602c5) M +5 -5 klipper/historyimageitem.cpp M +2 -2 klipper/historyimageitem.h M +3 -4 klipper/historyitem.h https://invent.kde.org/plasma/plasma-workspace/commit/89d1f0e07955427a083cbc5af34e0ae9fdcdaad4
*** This bug has been marked as a duplicate of bug 465225 ***