KDE systemsettings segfaults trying to enter kscreensaver settings app

I am experiencing a segmentation fault in the KDE systemsettings when trying to enter the screensaver settings. I think this is an old problem matching https://bugs.kde.org/show_bug.cgi?id=188623 but that problem started in 2009 and I don’t really see a resolution in it. I think that they may have finally been pointing at X or drivers as the problem, but I am unsure.

In my case, I am running openSuSE 13.1, 32-bit, on an Intel stl2 motherboard. Yast online update was run as recently as two weeks ago on the system, and I recollect seeing some service for Xorg coming in. This system using the ATI MACH64 driver from the 13.1 repositories. I reported a bug (865607) in Feb 2014 against opensuse 13.1 and the MACH64 driver, and it was fixed (thank you).

The traceback for this segfault problem on my system when trying to enter the kscreensaver settings to modify them is


Application: System Settings (systemsettings), signal: Segmentation fault
Using host libthread_db library "/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0xb15117c0 (LWP 2969))]

Thread 4 (Thread 0xadb4fb40 (LWP 2970)):
#0  0xb7747430 in __kernel_vsyscall ()
#1  0xb2c6ef3c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0xb5d31b5c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libc.so.6
#3  0xb3d71832 in ?? () from /usr/lib/libQtScript.so.4
#4  0xb3d7187f in ?? () from /usr/lib/libQtScript.so.4
#5  0xb2c6b07a in start_thread () from /lib/libpthread.so.0
#6  0xb5d24a9e in clone () from /lib/libc.so.6

Thread 3 (Thread 0xa6132b40 (LWP 2971)):
#0  0xb7747430 in __kernel_vsyscall ()
#1  0xb2c6ef3c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0xb5d31b5c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libc.so.6
#3  0xa76490c4 in ?? () from /usr/lib/dri/swrast_dri.so
#4  0xb2c6b07a in start_thread () from /lib/libpthread.so.0
#5  0xb5d24a9e in clone () from /lib/libc.so.6

Thread 2 (Thread 0xa5931b40 (LWP 2972)):
#0  0xb7747430 in __kernel_vsyscall ()
#1  0xb2c6ef3c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0xb5d31b5c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libc.so.6
#3  0xa76490c4 in ?? () from /usr/lib/dri/swrast_dri.so
#4  0xb2c6b07a in start_thread () from /lib/libpthread.so.0
#5  0xb5d24a9e in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb15117c0 (LWP 2969)):
[KCrash Handler]
#6  0xb3030754 in XVisualIDFromVisual () from /usr/lib/libX11.so.6
#7  0xb66e8ab4 in ?? () from /usr/lib/libQtGui.so.4
#8  0xb66ea87b in QWidgetPrivate::create_sys(unsigned long, bool, bool) () from /usr/lib/libQtGui.so.4
#9  0xb669a02d in QWidget::create(unsigned long, bool, bool) () from /usr/lib/libQtGui.so.4
#10 0xa7c8da83 in ?? () from /usr/lib/kde4/kcm_screensaver.so
#11 0xa7c84e6c in ?? () from /usr/lib/kde4/kcm_screensaver.so
#12 0xa7c86965 in ?? () from /usr/lib/kde4/kcm_screensaver.so
#13 0xb6065c55 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4
#14 0xb60b6895 in QTimer::timeout() () from /usr/lib/libQtCore.so.4
#15 0xb606f516 in QTimer::timerEvent(QTimerEvent*) () from /usr/lib/libQtCore.so.4
#16 0xb606a11c in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4
#17 0xb664a4b4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#18 0xb6650ee3 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#19 0xb71adcb4 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5
#20 0xb6050fba in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4
#21 0xb60833af in ?? () from /usr/lib/libQtCore.so.4
#22 0xb6080398 in ?? () from /usr/lib/libQtCore.so.4
#23 0xb2ba67de in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#24 0xb2ba6b88 in ?? () from /usr/lib/libglib-2.0.so.0
#25 0xb2ba6c48 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#26 0xb60805ef in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#27 0xb66fa51e in ?? () from /usr/lib/libQtGui.so.4
#28 0xb604fa03 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#29 0xb604fd29 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#30 0xb60554fe in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#31 0xb6648944 in QApplication::exec() () from /usr/lib/libQtGui.so.4
#32 0x08050f10 in ?? ()
#33 0xb5c509d3 in __libc_start_main () from /lib/libc.so.6
#34 0x08050f51 in _start ()

Desktop effects are turned off at startup.

Content of the current $HOME/.kde4/share/config/kscreensaverrc is:


[ScreenSaver]
LegacySaverEnabled=true
PlasmaEnabled=false
Saver=kblank.desktop
Timeout=360

As I mentioned above, this seems to be an old bug matching the one I cited, so I am unsure if I should open a new bug or if someone has a suggestion on how to proceed.

Try to boot to recovery mode and see if the problem persists.
If not it’s likely a graphics driver problem.

I don’t have a problem here btw, and never had. But I don’t use the mach64 driver.

As I mentioned above, this seems to be an old bug matching the one I cited, so I am unsure if I should open a new bug or if someone has a suggestion on how to proceed.

I don’t think it makes sense to open a new bug. You could add a comment to the existing one, but I don’t think this will help much either.
KDE4 is nearly at the end of its life, and the screensaver support has been removed completely in Plasma5.

And again, this doesn’t seem to be a general problem. If it’s caused by the graphics driver or Mesa, there’s not much KDE can do about it anyway.

Also, the KDE in 13.1 is quite old, you might try to update to the latest version from the KDE:Current repo though:
https://en.opensuse.org/SDB:KDE_repositories

And/or try to upgrade Xorg and Mesa to the latest versions from the [noparse]X11:XOrg[/noparse] repo… But in that case a complete upgrade to 13.2 might be preferable. Maybe try a 13.2 LiveCD as a test.

OTOH, if it’s only the screensaver config module crashing, I suppose I wouldn’t bother too much.

Ok. It will be a few hours before I can try the recovery mode experiment. Also downloading the 13.2 live cd now to give it a try, too. Will post results later.

Ok. Here is what occurred with some of the tests.

When the system was booted into recovery mode, the failure did not occur.

We tried but were unable to test the Live-KDE DVD for 13.2 because the kernel on that DVD lacks a fix for a problem that one of my colleagues reported against the kernel’s pata_serverworks driver that drives the IDE DVD drive that affects this motherboard. The patch was accepted, and we were expecting it to be in opensuse 13.2 when 13.2 was first released, but something caused that patch to not flow from upstream (I think it was the fault of the developer). Reference:

In any case, since we proved that recovery mode on 13.1 seems to have a positive effect that going through machinations to try and get the patched pata_serverworks loaded when booting a Live DVD (it’s bad enough when we install openSuSE 13.1 just to be able to complete the installation) that we have a valid data point.

I grabbed a copy of the current Tumbleweed KDE-LIVE DVD and we tried that on the system. The kernel appears to contain the patched pata_serverworks and it booted. But the X display was pretty unusable. We managed to get switched over to one of the other TTY terminals and were able to see that it was using MACH64, but was using an 1152x864 resolution. We managed to pull the /etc/X11/xorg.conf.d/ files off of the server’s hard drives and replace those on the ram disk in /etc/X11/xorg.conf.d/ and restart X which got us a useable X configuration.

From there, we were able to get into the equivalent (though different, and not equipped like screensaver app in opensuse 13.1) Screen Locking Timeouts app without it segfaulting. Not sure how good a test that is given the difficulties we had to overcome with X on the DVD, but we made it that far. Another data point.

Yes, according to the links you posted, that fix was added to Kernel 3.17+ only. Might have been or might be backported by openSUSE to their 3.16 kernel though, but it’s probably not in the one that’s shipped on the installation medium (3.16.6).

From there, we were able to get into the equivalent (though different, and not equipped like screensaver app in opensuse 13.1) Screen Locking Timeouts app without it segfaulting. Not sure how good a test that is given the difficulties we had to overcome with X on the DVD, but we made it that far. Another data point.

Unfortunately that doesn’t prove anything. Tumbleweed uses Plasma5 already (since about a month), where support for screensavers has been dropped completely. That’s why I didn’t suggest that, only a 13.2 LiveCD.
Plasma5’s screenlocker settings is pretty boring, just a few checkboxes, a number input, and a button to choose a wallpaper. I would expect that not to crash under any circumstances…

I think what is crashing on your system is the screensaver preview, at least that’s what I would guess.
What happens when you run “kblankscrn.kss” manually?

As I said, I wouldn’t bother much about a not-working configuration module. But if the screensaver itself crashes, you might have problems whenever it kicks in.
I don’t know what your actual desire is, but you could of course configure the screensaver by editing that config file ($HOME/.kde4/share/config/kscreensaverrc) directly with a text editor.
Set “LegacySaverEnabled=false” to disable screensavers completely (you will just get the standard lockscreen then), I would wager that the settings module won’t crash then either any more.
Or you can choose the screensaver to be used with the “Saver=” line. The screensavers are just normal executables. Some are located in /usr/bin/ and have the suffix .kss (use “ls /usr/bin/*.kss” to list them), others are in /usr/share/kde4/services/ScreenSavers/.
If you want to be asked for a password to unlock the screen, set “Lock=true”.

Or as it doesn’t crash in recovery mode, you could just configure it there and then reboot to normal mode afterwards (the settings will be retained).

Of course in either case, you shouldn’t configure a screensaver that’s crashing in normal mode, if that’s the actual problem…
You can run them manually in Konsole to find out whether a particular one works or not. Just type xxx.kss for the first category, or have a look into the .desktop file (it’s just a text file), the Exec= line specifies what exact command you’d need to run.

When I invoke kblankscrn.kss at a shell prompt in a konsole window, it opens a new konsole window in which the image is solid black. If I put “Saver=kblankscrn.kss” or “Saver=/usr/bin/klbankscrn.kss” in the $HOME/.kde4/share/config/kscreensaverrc file, then when the timer is met it shows the default saver background (black with chameleon and vine) as opposed to the desired solid black as when “Saver=kblank.desktop” is specified.

Yes, I have confirmed that manually editing the file to change the Timeout= and then logging out and back in circumvents the segfault and inability to alter the contents via the graphical window.

Confirmed that “LegacySaverEnabled=false” will get you the standard lockscreen background image independent of “Saver=” specification. However, you would lose the wager as it still segfaults no matter what is specified for “LegacySaverEnabled=” and “Saver=”.

I think I have enough circumventions in hand to not warrant a lot of effort to fix the issue. It is disconcerting that the original bug that I cited in kde never seemed to be resolved. If I had another kde4 app that was segfaulting, I would be more tenacious. But as it is, there is just this annoying inability to alter the settings graphically using kde4’s own app for that purpose. If they are dropping all support for screensavers, then it seems unworthy of further pursuit.

No, it doesn’t open a new “konsole window”. It opens a “screensaver” window in which the screensaver runs (this particular one only “draws” a black background though).

If I put “Saver=kblankscrn.kss” or “Saver=/usr/bin/klbankscrn.kss” in the $HOME/.kde4/share/config/kscreensaverrc file, then when the timer is met it shows the default saver background (black with chameleon and vine) as opposed to the desired solid black as when “Saver=kblank.desktop” is specified.

Right, you should specify the .desktop file from /usr/share/kde4/services/ScreenSavers/ in any case.
I got confused myself, sorry.

The lock screen always displays the default wallpaper as background (to hide the desktop), and then it runs the screensaver on top of that.
If running the screensaver fails (or you haven’t configured a screensaver at all), you just see the default wallpaper.

Yes, I have confirmed that manually editing the file to change the Timeout= and then logging out and back in circumvents the segfault and inability to alter the contents via the graphical window.

So the systemsettings module does not segfault when you set a different timeout value? Strange, and rather unlikely IMHO.
Are you sure you didn’t change anything else? Does it crash again if you set the timeout back to 360?

Confirmed that “LegacySaverEnabled=false” will get you the standard lockscreen background image independent of “Saver=” specification.

Yes, see above.

However, you would lose the wager as it still segfaults no matter what is specified for “LegacySaverEnabled=” and “Saver=”.

Well, ok. Then it does not crash because of that embedded screensaver. Would have been the most likely reason for me though.
I owe you a beer then, I guess… :wink:

I think I have enough circumventions in hand to not warrant a lot of effort to fix the issue. It is disconcerting that the original bug that I cited in kde never seemed to be resolved. If I had another kde4 app that was segfaulting, I would be more tenacious. But as it is, there is just this annoying inability to alter the settings graphically using kde4’s own app for that purpose. If they are dropping all support for screensavers, then it seems unworthy of further pursuit.

Well, it is definitely not a general problem. It only happens on some systems.
E.g. I never saw such a crash at all here on several systems.
And again, if it’s a bug in the graphics driver(s), there’s not much KDE can do about it anyway.