Feature request: A backtrace for Kwin may be obtained when running Plasma using the instructions [here](https://community.kde.org/KWin/Debugging#TL;DR_for_bug_reporters). This is a little bit non-trivial; I haven't tried this for X11, but for Wayland, an SSH session is mandatory, and if using a login manager, it requires one to log in separately over the network, set things up, then go back into the desktop session. Because I'm on an NVidia system, I sometimes find SDDM is a bit wobbly, sometimes things freeze up when changing TTYs, and sometimes starting a shell from the TTY produces different behaviour from starting it through SDDM. From experience (I've not yet read the code, so I don;t know the full architecture), startplasma-wayland appears to run KWin in a crashloop - i.e. when KWin does crash, I usually get a fresh blank desktop, and I see a kwin_wrapper process running. What I'd like to propose, is ask if it is possible for plasma to run that kwin session under gdb/another system debugger (maybe only LLDB is installed, but this would be an enhancement), and automatically log a backtrace to journalctl (or another place if more appropriate). That way, the information may be obtained in a more preventative manner, however it is I start the desktop, rather than needing explicit steps form me first. Personally, and very unfortunately, I am running this system where I need an NVidia card. On top of that the motherboard has an integrated VGA header (for headless server use), so it's in effect a multi-GPU setup. Thus desktop crashes have been a relatively common experience for a long time using various distros. The logs are often filled with error messages that may be ignored, and then suddenly when I do experience a crash, bisecting the point at which something actually failed is quite tricky. A backtrace is somewhat less ambiguous, at the leats I should be able to see what actually failed, and the logs may then help in working out why. Without always knowing what will precipitate a crash, it's hard for me to forcibly reproduce one, and as plasma is my desktop, according to Murphy's law it happens right when I am in the middle of something, have lots of unsaved work, and no time to investigate properly. Therefore, I think the process of generating more debug information when KWin crashes might help with development quite a lot. I've seen many bugs under all desktops with the transition to Wayland and especially with Nvidia, so whilst the linked article is helpful, I hope having an automatic process (if possible - maybe it just isn't) might help squash some of these. # Possible implementations Producing the backtrace would generally require the debug symbols to be installed, as well as an appropriate debugger. Therefore, I see two possible ways to achieve this: 1) Automatically sense on startup if the prerequisites are installed; if so, launch KWin under a debugger and dump the crash information in Plasma's crashloop. 2) Add a separate startplasma-... command and login manager session (e.g. Plasma (Wayland; debug)). Downstream packagers could consider adding these with the debug symbols for the package, so that normal users without symbols installed would not see it in their options. If the required dependencies are not detected, do not start the desktop, and exit. Also, I'm not necessarily recommending that this would be something that would be installed or burden the average user. Running kwin under a debugger should carry performance implications, so this ought to be an opt-in step for someone who is experiencing crashes to follow. It should also be something that can be enabled or disabled easily, so that a user can differentiate between a normal and a debug desktop session as appropriate, again akin to installing debug symbols for a package. The idea is to make it easier for a user familiar with sysadmin and collecting logs and debug information, but not necessarily as familiar with the complexities of doing so for a desktop session and specifically for KWin/Plasma, to be able to provide the developers with required diagnostic information. Unless it's possible to achieve this without a penalty (which I don't think it is, my own applications run much slower when reading in symbols, but will happily stand corrected, I don;t know much about coredumpctl and friends), then they probably shouldn't pay the price. Thanks for the continued work! Having migrated to SUSE, it's nice to see wayland support steadily coming along during a pretty rocky few years for the linux world.
In fact we do already have automatic bug reporting, but you have to opt in. The first time there's a KWin crash, you should see the DrKonqi crash reporter wizard window appear, and in that window there's an option to automatically report crashes in the future. I know this works because we have tons and tons of automatic KWin crash reports in the database. :) If this isn't working, perhaps you uninstalled or disabled DrKonqi? Or maybe your distro did in favor of their own system?
Thanks for getting back to me quickly, DrKonqi is installed, but generally hasn't shown up for past KWin crashes. I guessed that gathering that info might be more complicated than it could provide - e.g. that it was designed around single applications, not the whole windowing system. I have now seen my first one a few days ago though so clearly it works sometimes. I still believe it'd be useful to be able to gather this info more suitably for e.g. launching from a TTY. If I have to restart Plasma to get the window up, wait for a load of previous applications to try to relaunch themselves, then hope that the coredump can be read, etc. If the crash happens overnight then it may be several hours until I'm awake to take a look which makes it harder to collate that information, I'm not sure how long core dumps persist on this machine, and it needs root access too. And after one just now the machine is whirring away like mad trying to gather the information as well as restart what I had open, and I was just seeing a lot of "Python exception: value has been optimized out" messages for about five minutes until it finally got me a trace. So in terms of bisecting the error I reckon it'd still be helpful to have as an option getting a backtrace into the systemd logs at the exact point it went down, so I can more clearly see what just happened, rather than try to post-mortem next time the shell comes back up.. The UI all good stuff for regular users, but as a poweruser, if I could e.g. wrap a plasma session with/alongside DrKonqi from a TTY or otherwise, so I automatically get the info, maybe specify a path to save timestamped logs (or I can do that myself), get it in the journal, I think that would help in isolating patterns of what happens. Maybe some of this can be done already; and if so, then it'd be great to have that in the wiki, as it doesn't really cover it in more detail. When I have a spare minute I'll look to see more on how it works and what options there are. Thanks