Bug 508177

After trying to find a solution for my crash, and looking into older bug reports of similar problems, I got sddm to start again if I have QML_DISABLE_DISK_CACHE=1 as a global envar.

Does this help diagnosing what caused the most recent updates to Neon testing to cause the crashes?

I can confirm this - SDDM crashing also occurring on my system (Intel X1 Carbon Gen 2, Neon testing).  System logs show libQt6Core.so.6 as faulting, can manually start plasmashell but it coredumps, too;

Coredump showed these libs in the backtrace:
libQt6Core.so.6 (Qt6)
libstdc++.so.6, libgcc_s.so.1 (GCC 14 runtime)
libsystemd.so.0, libudev.so.1 (systemd)
libgomp.so.1 (OpenMP), libzstd.so.1 (zstd)

Reinstalled the OS and it's all fine, then to confirm the bug I accepted most recent updates and I see the exact same behaviour again.

The crash solved itself with the current updates, but this kind of crash and unusable system happened a few times in the last year. I think since some bug in QT 6.8, which was also mitigated with an environment variable.

Is there any way to make sddm and plasmashell more robust to a small change in a QT lib?

I was able to fix my system UI until an update solved the crash, but other users ended up reinstalling the whole system. I understand Testing is for... testing! But if you want to help test, and report bugs, some kind of failsafe system when QT apps are not running correctly could be interesting to have so a user could at least make updates. If sddm crashes on boot, a very simple UI (something that could work even if some QT lib is creating crashes or missing due to some packaging issue) is started that allows to apply updates. "It seems your graphical environment isn't working correctly. Do you want to try to update your system to see if a fix has been released? Login with your user and check for updates: User: Password: etc etc". It could allow for reporting a crash on boot too. If systemd keeps track of crashes, it could use this feature to allow to submit a bug report of the boot process crash. 
One can always use the console, nmcli up the network connection and use apt, but not every user knows how to do this, but still be interested in using Testing to contribute to test the graphical system and apps.

a new snapshot has been made that fixes the bic caused by a new version of wayland and libinput being released.

*** Bug 508126 has been marked as a duplicate of this bug. ***

(In reply to Bruno Santos from comment #3)
> The crash solved itself with the current updates, but this kind of crash and
> unusable system happened a few times in the last year. I think since some
> bug in QT 6.8, which was also mitigated with an environment variable.
> 
> Is there any way to make sddm and plasmashell more robust to a small change
> in a QT lib?
> 
> I was able to fix my system UI until an update solved the crash, but other
> users ended up reinstalling the whole system. I understand Testing is for...
> testing! But if you want to help test, and report bugs, some kind of
> failsafe system when QT apps are not running correctly could be interesting
> to have so a user could at least make updates. If sddm crashes on boot, a
> very simple UI (something that could work even if some QT lib is creating
> crashes or missing due to some packaging issue) is started that allows to
> apply updates. "It seems your graphical environment isn't working correctly.
> Do you want to try to update your system to see if a fix has been released?
> Login with your user and check for updates: User: Password: etc etc". It
> could allow for reporting a crash on boot too. If systemd keeps track of
> crashes, it could use this feature to allow to submit a bug report of the
> boot process crash. 
> One can always use the console, nmcli up the network connection and use apt,
> but not every user knows how to do this, but still be interested in using
> Testing to contribute to test the graphical system and apps.

hopefully the link below explains the situation and the extra steps that have been implemented in the past year to try and stop this occurring -  https://bugs.kde.org/show_bug.cgi?id=508126#c6

(In reply to Carlos De Maine from comment #4)
> a new snapshot has been made that fixes the bic caused by a new version of
> wayland and libinput being released.

Has this change been applied to Neon Test?  I just received an update to sddm but the problem reported persists.

(In reply to David R. Bergstein from comment #7)
> (In reply to Carlos De Maine from comment #4)
> > a new snapshot has been made that fixes the bic caused by a new version of
> > wayland and libinput being released.
> 
> Has this change been applied to Neon Test?  I just received an update to
> sddm but the problem reported persists.

i can confirm and i'm confused.  packagekit-qt was bumped to a new version for plasma-discover and and it's dependees were rebuilt (none of which affect sddm) but sddm-greeter-qt is now exploding in qtdeclarative.

systemctl stop sddm.service. and then startplasma-wayland can run an entire plasma session when invoked from a terminal from though \o/

(In reply to David R. Bergstein from comment #7)
> (In reply to Carlos De Maine from comment #4)
> > a new snapshot has been made that fixes the bic caused by a new version of
> > wayland and libinput being released.
> 
> Has this change been applied to Neon Test?  I just received an update to
> sddm but the problem reported persists.

okay, finally worked it out.  the crash in the journal referenced qtdeclarative and then plasmacomponents.  sure enough a rebuild of libplasma and sddm fires up again.  this is fixed in the stable staging archive, just waiting on the 25.08 gear release to finish building and the will snapshot to testing.

The problem returned after some other updates yesterday. sddm-greeter crashes on boot.

Created attachment 184137 [details]
Backtrace for sddm-greeter crash

(In reply to Bruno Santos from comment #12)
> Created attachment 184137 [details]
> Backtrace for sddm-greeter crash

as noted in comment 10
"okay, finally worked it out.  the crash in the journal referenced qtdeclarative and then plasmacomponents.  sure enough a rebuild of libplasma and sddm fires up again.  this is fixed in the stable staging archive, just waiting on the 25.08 gear release to finish building and the will snapshot to testing."

new snapshot out, tested in vm with no crashes