kcminit crash on login

I switched from Leap 15 to Tumbleweed 20180620 and I’m now seeing a kcminit crash on login:

startkde: Starting up...
KCrash: Application 'kdeinit5' crashing...
KCrash: Attempting to start /usr/lib64/libexec/drkonqi from kdeinit

I’ve reported this by following the “Report Bug” which raises a bug at https://bugs.kde.org/show_bug.cgi?id=395779 - it may be a duplicated of https://bugs.kde.org/show_bug.cgi?id=394534 which is marked as resolved. The bug does not prevent login from completing.

Questions:

  1. Do I also need to raise a bug at https://bugzilla.opensuse.org in order to get it more promptly resolved in tumbleweed?
  2. Would it be better not to submit the automatic reporting to bugs.kde and just report the stack trace directly to bugzilla.opensuse.org?

Reported stack trace was as follows:

Application: kdeinit5 ()
Qt Version: 5.11.0
Frameworks Version: 5.46.0
Operating System: Linux 4.17.2-1-default x86_64
Distribution: "openSUSE Tumbleweed"

-- Information about the crash:
- What I was doing when the application crashed:

Logging in.  Also happens when logging in as other users.

Just converted to openSUSE tumbleweed today.  OpenSUSE Leap 15 was working fine with it's older version of KDE.

-- Backtrace:
Application: KCMInit (kdeinit5), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f820bce5380 (LWP 10413))]

Thread 3 (Thread 0x7f81f4f87700 (LWP 10424)):
#0  0x00007f820840e7ff in pthread_getspecific () from /lib64/libpthread.so.0
#1  0x00007f8206247120 in g_thread_self () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f820621f3dd in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f820a32c90b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#4  0x00007f820a2dc9fb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#5  0x00007f820a13b356 in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#6  0x00007f820126ef45 in ?? () from /usr/lib64/libQt5DBus.so.5
#7  0x00007f820a14493c in ?? () from /usr/lib64/libQt5Core.so.5
#8  0x00007f8208407554 in start_thread () from /lib64/libpthread.so.0
#9  0x00007f8209db2fdf in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f81f7527700 (LWP 10415)):
#0  0x00007f8209da85d9 in poll () from /lib64/libc.so.6
#1  0x00007f820b145377 in ?? () from /usr/lib64/libxcb.so.1
#2  0x00007f820b146f8a in xcb_wait_for_event () from /usr/lib64/libxcb.so.1
#3  0x00007f81f9f19939 in ?? () from /usr/lib64/libQt5XcbQpa.so.5
#4  0x00007f820a14493c in ?? () from /usr/lib64/libQt5Core.so.5
#5  0x00007f8208407554 in start_thread () from /lib64/libpthread.so.0
#6  0x00007f8209db2fdf in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f820bce5380 (LWP 10413)):
[KCrash Handler]
#6  0x00007f82015081ea in QMapData<KEntryKey, KEntry>::findNode (this=0x4545454545454545, akey=...) at /usr/include/qt5/QtCore/qmap.h:284
#7  0x00007f820150d39b in QMap<KEntryKey, KEntry>::constFind (this=0x561b81397d40, akey=...) at /usr/include/qt5/QtCore/qmap.h:874
#8  QMap<KEntryKey, KEntry>::find (akey=..., this=0x561b81397d40) at /usr/include/qt5/QtCore/qmap.h:876
#9  KEntryMap::findEntry (this=this@entry=0x561b81397d40, group=..., key=..., flags=...) at /usr/src/debug/kconfig-5.46.0-1.2.x86_64/src/core/kconfigdata.cpp:74
#10 0x00007f820150d4bb in KEntryMap::getEntry (this=this@entry=0x561b81397d40, group=..., key=..., defaultValue=..., flags=..., flags@entry=..., expand=0x7ffdc76cfb07) at /usr/src/debug/kconfig-5.46.0-1.2.x86_64/src/core/kconfigdata.cpp:224
#11 0x00007f8201501929 in KConfigPrivate::lookupData (this=this@entry=0x561b81397d20, group=..., key=key@entry=0x7f81f4579c67 "cursorTheme", flags=..., flags@entry=..., expand=expand@entry=0x7ffdc76cfb07) at /usr/include/qt5/QtCore/qarraydata.h:255
#12 0x00007f82015112ee in KConfigGroup::readEntry (this=this@entry=0x7ffdc76cfba0, key=key@entry=0x7f81f4579c67 "cursorTheme", aDefault=...) at /usr/include/qt5/QtCore/qflags.h:120
#13 0x00007f81f4567844 in X11Backend::kcmInit (this=0x561b8137acb0) at /usr/include/qt5/QtCore/qarraydata.h:255
#14 0x00007f81f455f25a in kcminit_mouse () at /usr/src/debug/plasma5-desktop-5.13.0-1.1.x86_64/kcms/mouse/kcm/configcontainer.cpp:32
#15 0x00007f81facac86d in KCMInit::runModule (this=this@entry=0x7ffdc76cff20, libName=..., service=...) at /usr/src/debug/plasma5-workspace-5.13.0-1.1.x86_64/startkde/kcminit/main.cpp:87
#16 0x00007f81facad2f5 in KCMInit::runModules (this=this@entry=0x7ffdc76cff20, phase=phase@entry=0) at /usr/include/c++/8/bits/atomic_base.h:295
#17 0x00007f81facad6c1 in KCMInit::KCMInit (this=0x7ffdc76cff20, args=...) at /usr/src/debug/plasma5-workspace-5.13.0-1.1.x86_64/startkde/kcminit/main.cpp:171
#18 0x00007f81facae5af in kdemain (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/plasma5-workspace-5.13.0-1.1.x86_64/startkde/kcminit/main.cpp:241
#19 0x0000561b7fb84d87 in launch (argc=1, _name=0x561b8124f2a1 "kcminit_startup", args=<optimized out>, cwd=<optimized out>, envc=0, envs=<optimized out>, reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x561b7fb87593 "0") at /usr/src/debug/kinit-5.46.0-1.2.x86_64/src/kdeinit/kinit.cpp:705
#20 0x0000561b7fb8163f in main (argc=5, argv=<optimized out>) at /usr/src/debug/kinit-5.46.0-1.2.x86_64/src/kdeinit/kinit.cpp:1744

This is probably the same bug:https://bugzilla.opensuse.org/show_bug.cgi?id=1097943

It should be fixed in Plasma 5.13.1 that has been submitted to TW a few days ago already.

Should be in the standard TW repos soon.

Good news - thanks.

I think my other questions have also been addressed. It seems tumbleweed is truly leading edge and tracks upstream KDE very closely. It’s bit of a change to be on the leading edge after having been using Leap for so long. So far, this relatively minor bug aside, the experience is positive (but it’s only been 24 hours).

Indeed. We try to submit new upstream versions to TW ASAP (often even on the same day as they are released). Updates do take a couple of days to go through Tumbleweed’s review and staging process, but an openSUSE bug report won’t speed that up either.

So in general it is better to report crashes (or other problems) directly to the upstream KDE developers (unless they are clearly packaging issues).
TW will inherit upstream fixes automatically anyway.

(for a fixed release like Leap one would need to open a bug report against openSUSE to get a backport)