Bug 328478

Summary:	sudden crash when changing userpersonality with ctrl+alt+respective F(e.g. 7,8,9) combination
Product:	[Unmaintained] kdelibs	Reporter:	stakanov.s
Component:	kdeinit	Assignee:	kdelibs bugs <kdelibs-bugs>
Status:	RESOLVED DUPLICATE
Severity:	crash	CC:	cfeck
Priority:	NOR	Keywords:	drkonqi
Version:	unspecified
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description stakanov.s 2013-12-06 10:12:30 UTC

Application: kcminit ()
KDE Platform Version: 4.11.2
Qt Version: 4.8.5
Operating System: Linux 3.11.6-4-desktop x86_64
Distribution: "openSUSE 13.1 (Bottle) (x86_64)"

-- Information about the crash:
- What I was doing when the application crashed:
Switching from terminal f8 to f7 where another user session was running. Unblocking screen by moving the mouse (as screen lock with password is apparently not forseen in this asset - no screenlock when using function keys, do not know if this is normal)
- Unusual behavior I noticed:
Screen goes black suddenly. Before it seemed that the screen was somehow esitating to unlock. Screen was then back and Dr Konqui appeared. 

This is a standard installation of openSUSE 13.1. Only particularity is the screen setup. A Lenovo X201 laptop on an ultrabase, the screens (two) are attached in the following way: 
On the displayport the HDMI screen, on the VGA port an older VGA screen. Screens are set to dive an enalrged total screen with separate screen contents (wallpaper/ apps/ widgets). Since 13.1 this works quite well, normally.

-- Backtrace:
Application: KCMInit (kcminit), signal: Aborted
Using host libthread_db library "/lib64/libthread_db.so.1".
[KCrash Handler]
#5  0x00007f8ce6855849 in raise () from /lib64/libc.so.6
#6  0x00007f8ce6856cd8 in abort () from /lib64/libc.so.6
#7  0x00007f8ce52cd204 in qt_message_output(QtMsgType, char const*) () from /usr/lib64/libQtCore.so.4
#8  0x00007f8ce6323009 in QDebug::~QDebug (this=0x7fff460dc580, __in_chrg=<optimized out>) at /usr/include/QtCore/qdebug.h:85
#9  0x00007f8ce63fb268 in KApplicationPrivate::init (this=0x15979e0, GUIenabled=GUIenabled@entry=true) at /usr/src/debug/kdelibs-4.11.2/kdeui/kernel/kapplication.cpp:516
#10 0x00007f8ce63fbc52 in KApplication::KApplication (this=0x7fff460dc770, GUIenabled=true) at /usr/src/debug/kdelibs-4.11.2/kdeui/kernel/kapplication.cpp:352
#11 0x00007f8ce6bd4539 in kdemain (argc=2, argv=0x7fff460dc8d8) at /usr/src/debug/kde-workspace-4.11.2/kcminit/main.cpp:262
#12 0x00007f8ce6841be5 in __libc_start_main () from /lib64/libc.so.6
#13 0x0000000000400761 in _start () at ../sysdeps/x86_64/start.S:122

Possible duplicates by query: bug 318467, bug 314342.

Reported using DrKonqi

Comment 1 stakanov.s 2013-12-06 10:33:26 UTC

This is actually repeatable:

Application: KCMInit (kcminit), signal: Aborted
Using host libthread_db library "/lib64/libthread_db.so.1".
[KCrash Handler]
#6  0x00007f80da286849 in raise () from /lib64/libc.so.6
#7  0x00007f80da287cd8 in abort () from /lib64/libc.so.6
#8  0x00007f80d8cfe204 in qt_message_output(QtMsgType, char const*) () from /usr/lib64/libQtCore.so.4
#9  0x00007f80d9d54009 in QDebug::~QDebug (this=0x7fffef8c43b0, __in_chrg=<optimized out>) at /usr/include/QtCore/qdebug.h:85
#10 0x00007f80d9e2c268 in KApplicationPrivate::init (this=0xbfb9e0, GUIenabled=GUIenabled@entry=true) at /usr/src/debug/kdelibs-4.11.2/kdeui/kernel/kapplication.cpp:516
#11 0x00007f80d9e2cc52 in KApplication::KApplication (this=0x7fffef8c45a0, GUIenabled=true) at /usr/src/debug/kdelibs-4.11.2/kdeui/kernel/kapplication.cpp:352
#12 0x00007f80da605539 in kdemain (argc=2, argv=0x7fffef8c4708) at /usr/src/debug/kde-workspace-4.11.2/kcminit/main.cpp:262
#13 0x00007f80da272be5 in __libc_start_main () from /lib64/libc.so.6
#14 0x0000000000400761 in _start () at ../sysdeps/x86_64/start.S:122

When this happens, no application can be launched anymore until kcminit is restarted. The apps that one tries to open "pile up" and open in sequence once this is done (giving way of course to a multitude of windows).

Comment 2 Jekyll Wu 2013-12-12 09:58:41 UTC

The backtrace implies dbus not running ?

Comment 3 stakanov.s 2013-12-12 10:52:11 UTC

Well, I cannot tell you, I do not have the skills to answer you on this. If dbus is not running, I shall take the backtrace to suse and file a bug about dbus crashing I guess. Currently it does not happen anymore. But I switched to 4.11.3

Comment 4 Christoph Feck 2013-12-20 13:24:29 UTC


*** This bug has been marked as a duplicate of bug 270442 ***