SUMMARY occasionally, kwin_wayland crashes, bringing down the whole session and forcing one to restart. STEPS TO REPRODUCE 1. Use computer for a long while 2. After a time, kwin_wayland will crash and take down the whole session 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.21.0 KDE Frameworks Version: 5.79 Qt Version: 5.15.2 ADDITIONAL INFORMATION I am running KDE from the zawertun/kde COPR.
Unfortunately the core dump is too big to upload here, so I uploaded it to google drive. https://drive.google.com/file/d/1Vs-XbMT9UGxqZ7Hg-K9tzVjp90P8IVxJ/view?usp=sharing
That's the whole core file, not the backtrace. You'll need to put it through gdb and run `bt` to get the backtrace itself.
I tried doing the above with a decompressed core dump, and it did not work, and ended with (gdb) bt #0 0x00007f2474f9dbd0 in ?? () Backtrace stopped: Cannot access memory at address 0x7ffc4820e640 How would I analyze the core dumps in a way that will give useful results? The core dump also had the following in it: Failed to read a valid object file image from memory. Core was generated by `kwin_wayland --wayland_fd 4 --xwayland /usr/libexec/startplasma-waylandsession'. Program terminated with signal SIGSEGV, Segmentation fault.
you would need to invoke it like this: gdb --args kwin_wayland --wayland_fd 4 --xwayland /usr/libexec/startplasma-waylandsession [path to coredump file]
I have tried running the above, and after installing debug symbols and running bt, I cannot seem to get it to say anything except "no stack". What am I doing wrong?
I don't know, sorry. :( Maybe someone more knowledgeable than me can help you.
kwin_wayland tends to produce improper core dumps due to being considered privileged. You need to log in via SSH, attach gdb as root to the running kwin_wayland ("sudo gdb -p $(pidof kwin_wayland)") and let it run (type "c" into gdb) until it crashes again. You can then fetch the backtrace by typing "bt" into gdb.
Is there a way to retrieve an existing one using coredumpctl without getting one with mangled symbols?
So the bug happened again, and I get the same errors when trying to retrive the backtrace from the core dump. is there any way to run it with gdb attached but without it being abhorrently slow? If there was a way to configure it to run with gdb all the time I could do that, as this crash happens once every few days.
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 is being discussed at https://invent.kde.org/plasma/kwin/-/issues/33. To make future coredumps more useful you can add the text "ExternalSizeMax=6G" to /etc/systemd/coredump.conf.
I haven't actually encountered the crash in a while. I will keep the bug open and change the core dump size, but if the crash doesn't happen in the next month or so it probably was fixed in 5.21.1.