When kwin_wayland crashes

[Martin Flöser]

Am 2018-05-17 16:32, schrieb Aleix Pol:
> Hey,
> Here's an issue I've seen and I'm pretty sure you've seen too. For any
> reason kwin crashes. SDDM kills the whole session and jumps back to
> the login UI
> 
> Tue 2018-05-15 15:22:30 CEST    669  1000  1000  11 truncated
> /home/apol/devel/kde5/bin/kwin_wayland
> Tue 2018-05-15 15:22:32 CEST  11004  1000  1000   6 present
> /home/apol/devel/kde5/lib64/libexec/drkonqi
> Tue 2018-05-15 15:22:32 CEST  11003  1000  1000   6 present
> /home/apol/devel/kde5/lib64/libexec/org_kde_powerdevil
> Tue 2018-05-15 15:22:32 CEST   1139  1000  1000   6 present
> /usr/lib/chromium/chromium
> Tue 2018-05-15 15:22:32 CEST    811  1000  1000   6 present
> /home/apol/devel/kde5/lib64/libexec/org_kde_powerdevil
> 
> 
> As you can see here, kwin crashes into a "truncated" state that
> doesn't allow us to get a backtrace. My guess there is that it's SDDM
> rushing to have it killed but I'm not sure that's actually the case.
> 
> Can anyone point me at what is actually happening on the SDDM side? I
> was thinking that ideally when the session is open again we'd see a
> kcrash dialog with the backtrace and the opportunity to report. Or at
> the very least, we need to be able to successfully query coredumpd.

KWin_Wayland doesn't support kcrash. When KWin_Wayland crashes the 
windowing system dies. Thus DrKonqi cannot connect to a windowing system 
and doesn't work. Due to that it's disabled in kwin_wayland binary.

If you want to get a backtrace the best bet is coredumpctl, but I had no 
real luck with it. I tend to try to reproduce crashes in a nested setup 
which I run directly through gdb.

Cheers
Martin