Created attachment 182489 [details] Backtrace fetched via "gdb --args /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet --testing" SUMMARY After installing the latest updates on a debian trixie/testing system, the screen locker stopped working. When locking the screen the fallback message, that the screen locker has failed and loginctl should be used to unlock, is shown. Further investigation with gdb shows, that kscreenlocker_greet segfault in libQt6Svg QSvgRenderer::load(QByteArray const&). Backtrace is attached. Clearing qt caches, setting qt to software rendering (QMLSCENE_DEVICE=softwarecontext) or reinstalling qt and plasma packages does not change the outcome. The issue can be mitigated by setting the lock screen background/wallpaper to an non-SVG image or the debian "Homeworld" SVG also works, other SVGs like "Ceratopsian", "Emerald" or any other debian provided SVG background I have tried causes the segfault. STEPS TO REPRODUCE 1. install latest packages on a debian trixie system 2. set lock screen background/wallpaper to debian's default ceratopsian 3. launch kscreenlocker_greet manually or just lock the screen OBSERVED RESULT Fallback message, that screen locker has failed is shown, session needs to be unlocked via other vt/loginctl EXPECTED RESULT Lock screen is shown SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian 13/Trixie/testing + Side loaded nvidia drivers (see additional information) KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.13.0 Qt Version: 6.8.2 ADDITIONAL INFORMATION The issue can NOT be observed on a second debian trixie system after installing the same updates. One difference, which might be important, is, that the affected system uses an nvidia GPU, the second one an Intel GPU. The nvidia driver is the current production branch 570 version from nvidia directly. I know this is discouraged but I just cannot reliably run a wayland session with the outdated drivers from the debian repos at all. I tried to rule out the nvidia drivers, though I'm not sure if there might still be a connection: - software rendering does not mitigate the issue - anything else regarding rendering, open gl etc. works fine on the nvidia GPU - a minimal qt example to load an SVG file on the affected system also works just fine - updated and rolled back the previous nvidia driver version - rebuilt nvidia kernel modules Maybe also interesting, this issue has actually happened for the first time a couple of months ago, after some qt packages where updated in debian trixie. Also a segfault in the SVG lib from qt. Back then the issue could be resolved permanently by clearing the qt caches or temporarily by setting qt to software rendering. The qt packages where not touched since then, the latest updates only included an update of libkscreenlocker to 6.3.5-1, from 6.3.4-1 among other supposedly unrelated packages. I tried to revert the libkscreenlocker package to 6.3.4-1, that did not fix the issue, though I am not sure how sound that configuration with just that packages reverted even is.
Can you attach an SVG wallpaper file that causes the crash for you?
(In reply to Nate Graham from comment #1) > Can you attach an SVG wallpaper file that causes the crash for you? Thanks for the reply. TL;DR: I don´t think this can be a screen locker issue anymore and if nobody else has any issues, is probably not worth to look into. For anybody still interested, the situation just got stranger: Since the debian theme folders contain multiple SVGs for different resolutions, I wanted to make sure to attach the exact one which is actually used. But whenever I manually selected one of the SVGs, everything works fine, the lock screen loads and the background is shown. After more testing, moving files around etc. this is what happens: - the segfault seems to occur exclusively for some of the default options in the plasma settings under screen locking / appearance - manually selecting (via + Add..) the exact same SVGs from the corresponding theme folders does not result in a segfault - not all default themes are affected, but about half of the ones included with debian trixie are (i.e. Ceratopsian, futurePrototype, Joy, Lines) - when moving the SVGs from an affected theme out of the way and replacing them with SVGs from a working theme, does not segfault (lockscreen shows other themes SVGs) Other observations: On some kscreenlocker_greet runs (with --testing) the following messages where shown: kf.coreaddons: Cache is inaccessible /home/dominik/.cache/plasma_theme_breeze-dark.kcache kf.coreaddons: Deleting corrupted cache "/home/dominik/.cache/plasma_theme_breeze-dark.kcache" kf.coreaddons: Cache is inaccessible /home/dominik/.cache/plasma_theme_breeze-dark.kcache kf.coreaddons: Even a brand-new cache starts off corrupted, something is seriously wrong. :-( kf.coreaddons: Couldn't establish file backed memory mapping, will fallback to anonymous memory This run though did not segfault but the lockscreen was shown and worked as expected. Manually deleting the plasma_theme_breeze_dark.kcache file also did not fix the issue when an affected default theme is selected. Since kscreenlocker_greet can show any SVG perfectly fine when selected manually, I don't think there is anything wrong here. I don´t really know what to make out of this anymore, there seems to be a very specific constellation required to trigger the issue. Also no matter what I tried, I could not reproduce it on another debian trixie machine.
Well, a crash in the screen locker is quite bad, even if it's hard to reproduce! So we should keep this open. Unfortunately the backtrace is pretty incomplete. Can you install debug symbols for plasma-workspace and frameworks-ksvg and regenerate the backtrace by running `coredumpctl gdb [id of the crash]` again?
Created attachment 182703 [details] Backtrace with debug symbols installed
(In reply to Nate Graham from comment #3) > Well, a crash in the screen locker is quite bad, even if it's hard to > reproduce! So we should keep this open. > > Unfortunately the backtrace is pretty incomplete. Can you install debug > symbols for plasma-workspace and frameworks-ksvg and regenerate the > backtrace by running `coredumpctl gdb [id of the crash]` again? Of course, the backtrace with debug symbols is added to the attachments now. Looks like there might be some precaching going on for the default theme graphics, and that cache is corrupted somehow? This was actually something I tried to rule out before by deleting every cache file I could find, that might be related to qt or the screen locker. To check if there is some in memory cache recreated at every boot, I also tried moving the SVGs out of place, reboot and then move them back in place after the reboot. That did not mitigate the issue, though I don´t know when those corrupted caches would be created, so my method might be insufficient.
Created attachment 182704 [details] Backtrace for different SVG (futurePrototype default theme), first run
Created attachment 182705 [details] Backtrace for different SVG (futurePrototype default theme), second run
Created attachment 182706 [details] Backtrace for different SVG (futurePrototype default theme), third run
I just noticed, there there seem to be at least two different paths to the segfault. Rerunning some tests with a different affected default theme (futurePrototype instead of Ceratopsian) results in a different backtrace. A second run then looks very similar to the Ceratopsian backtrace, then it seems to alternate back to the path of the first run on a third run.
Thanks. This seems to point to a bug in KSvg; at the minimum it shouldn't get memory corruption and crash like this, no matter what the calling code is doing. Could you please attach a wallpaper that can be used to reproduce the issue?
Sorry for the late response. As mentioned, there doesn't seem to be a wallpaper on its own, that triggers the issue. Anyway, I just wanted to do some more testing and assemble a list of debian default themes, that result in the segfault. Turns out, the issue is gone now, none of the default themes causes the issue anymore. Some packages where updated in trixie lately, I can only guess, that one of theses updates fixed the issue. I had a custom wallpaper selected in the meantime and didn't notice until now, that the default ones are working again. If there is anything else I can do to provide more information, I will gladly do so. Though since I still cannot find any other reports about that issue, I'm pretty sure, that there was something broken on this specific system and I just did not figure out the right spot to look at. Thanks for the support!
debian/trixie marian@linlap:~$ /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet Locked at 1752091051 kf.coreaddons: Cache is inaccessible /home/marian/.cache/plasma_theme_breeze-dark.kcache kf.coreaddons: Deleting corrupted cache "/home/marian/.cache/plasma_theme_breeze-dark.kcache" kf.coreaddons: Cache is inaccessible /home/marian/.cache/plasma_theme_breeze-dark.kcache kf.coreaddons: Deleting corrupted cache "/home/marian/.cache/plasma_theme_breeze-dark.kcache" kf.coreaddons: Cache is inaccessible /home/marian/.cache/plasma_theme_breeze-dark.kcache kf.coreaddons: Even a brand-new cache starts off corrupted, something is seriously wrong. :-( kf.coreaddons: Cache is inaccessible /home/marian/.cache/plasma_theme_breeze-dark.kcache kf.coreaddons: Couldn't establish file backed memory mapping, will fallback to anonymous memory kf.coreaddons: Even a brand-new cache starts off corrupted, something is seriously wrong. :-( kf.coreaddons: Couldn't establish file backed memory mapping, will fallback to anonymous memory Unlocked qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0 Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked When I remove svg related cache , there are no messages like above: marian@linlap:~$ rm .cache/ksvg-elements marian@linlap:~$ /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet Locked at 1752091122 Unlocked qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0 qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0 Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked Unlocked
I think I am seeing these crash(es) on Debian Trixie too. I filed this Debian bug recently: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113726. You can find the backtraces in the report. I have some saved core files if additional information is needed.