Red Hat Bugzilla – Bug 455130
can not start ksmserver, ASSERT: "d" in ... kdecore/kernel/kcomponentdata.cpp, line 158
Last modified: 2008-08-29 11:23:28 EDT
Just and fyi, haven't had much chance to look more, but kde-4.0.98 (built for
F-9 here), falls over with many-a-error of the form:
kdeinit4: preparing to launch /usr/libexec/kde4/klauncher
ASSERT: "d" in file
/builddir/build/BUILD/kdelibs-4.0.98/kdecore/kernel/kcomponentdata.cpp, line 158
kdeinit4: (klauncher /usr/libexec/kde4/klauncher) Pipe closed
unexpectedlykdeinit4: Pipe closed unexpectedly: No such file or director
Argh, sounds badly broken!
156 KStandardDirs *KComponentData::dirs() const
161 return d->dirs;
The code of KComponentData hasn't changed since September 2007. I think we need
a backtrace for this assertion failure.
Confirmed going back to kde-4.0.85 is ok, so seems to be something particular to
4.0.98. I'm tempted to try rebuilding everything again, to confirm it's just
not a quirk in my own builds (at least until we have any confirmation of folks
seeing this on rawhide too).
Once I confirm that, I'll get to work on getting a backtrace.
Fwiw, the 4.0.98 F-9 builds I'm using here are currently in repos at
How most folks will experience this is that login will fail with error:
can not start ksmserver
I've confirmed that a kdelibs build omitting our nocache and kstandarddirs
patches still exhibits this problem (so I'm hoping that means that those patches
don't contribute to it).
Any chance you can get a stack trace for that? It might help figuring out
what's going wrong.
(For those who haven't followed the discussion on IRC: I have fixed this in
4.0.98-2.fc10 by reverting a recent kinit change which triggered this bug, but
I think the kinit change was only uncovering a latent bug and want the real
issue to be fixed.)
I just committed a clean fix in 4.1.1-2. Details forthcoming in an upstream bug report.
Upstream bug report: https://bugs.kde.org/show_bug.cgi?id=170043