Bug 422061 - KDE4 applications aren't starting at all
Summary: KDE4 applications aren't starting at all
Alias: None
Product: Fedora
Classification: Fedora
Component: kdebase
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
Whiteboard: HotIssue
Depends On:
Blocks: KDE4Live
TreeView+ depends on / blocked
Reported: 2007-12-12 17:25 UTC by Sebastian Vahl
Modified: 2008-02-11 16:09 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-02-11 16:09:21 UTC

Attachments (Terms of Use)
output of "strace konsole" (31.98 KB, text/plain)
2007-12-12 17:26 UTC, Sebastian Vahl
no flags Details
backtrace in gdb for kwrite (4.48 KB, text/plain)
2007-12-12 17:29 UTC, Sebastian Vahl
no flags Details
last known working packages (17.97 KB, text/plain)
2007-12-12 23:19 UTC, Sebastian Vahl
no flags Details
Backtrace of kwrite with known-as-working f8 rpms (4.29 KB, text/plain)
2007-12-13 23:43 UTC, Sebastian Vahl
no flags Details
audit.log (170.25 KB, text/plain)
2007-12-17 19:33 UTC, Sebastian Vahl
no flags Details

Description Sebastian Vahl 2007-12-12 17:25:12 UTC
Description of problem:
All KDE4 applications aren't starting and also the whole desktop when logging 
in though kdm.

The login hangs at the "gears" in ksplash. The application are hanging right 
after startup. There are no relevant messages in /var/log/messages or 
~/.xsession-errors nor the applications started from a terminal with another 
window manager (I've used openbox and xterm here) are creating any output. 
They are just hanging (and not crashing).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. update to latest kde4
2. try to login

2. start a different window manager and a terminal and try to launch some 
Actual results:
all applications are hanging

Expected results:
applications should start normal

Additional info:
starting an app from a xterm and killing it with "killall -SIGABRT <appname>" 
don't produce any output and kcrashmanager don't appears.

Comment 1 Sebastian Vahl 2007-12-12 17:26:52 UTC
Created attachment 285911 [details]
output of "strace konsole"

Comment 2 Sebastian Vahl 2007-12-12 17:29:17 UTC
Created attachment 285921 [details]
backtrace in gdb for kwrite

Steps done to take this output:
1. gdb kwrite
2. run
3. waited a minute and nothing happens
4. killall -SIGABRT kwrite (from another terminal)
5. thread apply all bt

Comment 3 Kevin Kofler 2007-12-12 17:34:03 UTC
The backtrace shows one thread waiting for another thread, but... there _is_ no 
other thread! So we have a deadlock where a thread is waiting for a nonexistent 
other thread, that's pretty bad. :-(

Comment 4 Kevin Kofler 2007-12-12 17:35:28 UTC
PS: What I assume happened is that the other thread crashed/exited while 
holding the lock. :-(

Comment 5 Sebastian Vahl 2007-12-12 23:19:10 UTC
Created attachment 286311 [details]
last known working packages

This attachament is a package list of my last known as working livecd for
reference. This livecd was created in the middle of the openssl change
(2007-12-08) and I've rebuilt all used kde-3.97.0 packages against the old

Comment 6 Than Ngo 2007-12-13 10:03:36 UTC
Strange, i have current rawhide running on my test machine and haven't seen 
this issue. Could you please update the whole current rawhide and try again?

Comment 7 Sebastian Vahl 2007-12-13 13:45:52 UTC
(In reply to comment #6)
> Could you please update the whole current rawhide and try again?

The system is up-to-date (rawhide from 2007-12-12). I'm also seeing this in at 
least my last local spin of the kde 4 live cd (same day).

I've rebuilt the core desktop packages in mock for F8 (with "--define='fedora 
9') and there is no problem.

Comment 8 Kevin Kofler 2007-12-13 16:30:00 UTC
GCC bug? Maybe the breakage in GCC 4.3 was accidentally backported to 4.1-rhl? 
Or maybe this is related to the deadlocks which are being reported on 
Sadly all these are just theories right now. :-(

Comment 9 Sebastian Vahl 2007-12-13 22:49:01 UTC
Strange. I've updated another test installation on another pc to the latest 
rawhide and the bug doesn't happen. Then I've re-spinned a livecd and this 
also fails on the same pc.

Comment 10 Sebastian Vahl 2007-12-13 23:43:38 UTC
Created attachment 288141 [details]
Backtrace of kwrite with known-as-working f8 rpms

I've just tried to install my created f8-rpms (comment #7) on my problematic
rawhide installation. kdelibs and kdepimlibs were installed with "--nodeps"
because openldap and openssl are newer versions in rawhide. Then I've done the
same steps as in comment #2 to create the backtrace.
The strange thing here is: The behaviour seems to be the same. kwrite is not
complaining about missing libs and is just hanging. But I cannot say if the
backtrace is also the same.
The same rpms are working fine on the same machine on f8.

Comment 11 Sebastian Vahl 2007-12-14 00:29:54 UTC
Well, "hanging" also means that there is absolutely no output in a terminal like
it should be (here on f8):

Link points to "/tmp/kde-sebastian"
kwrite(3265)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open
ksycoca from  "/var/tmp/kdecache-sebastian/ksycoca4"
kwrite(3265)/kio (KDirWatch) KDirWatchPrivate::KDirWatchPrivate: Available
methods:  ("Stat", "FAM", "INotify")
kwrite(3265) KateRendererConfig::setSchemaInternal: Loading template colors 
kwrite(3265)/Kate (Scripting) KateJScriptHelpers::parseScriptHeader: Update
script:  "/usr/share/kde4/apps/katepart/jscript/sort.js"
kwrite(3265)/Kate (Scripting) KateJScriptHelpers::parseScriptHeader: found pair:
( "name"  |  "C++ Indenter" )
kwrite(3265)/Kate (Scripting) KateJScriptHelpers::parseScriptHeader: found pair:
( "author"  |  "Dominik Haumann <dhdev@gmx.de>" )
kwrite(3265)/Kate (Scripting) KateJScriptHelpers::parseScriptHeader: found pair:
( "license"  |  "LGPL" )
kwrite(3265)/Kate (Scripting) KateJScriptHelpers::parseScriptHeader: found pair:
( "version"  |  "1" )
kwrite(3265)/Kate (Scripting) KateJScriptHelpers::parseScriptHeader: found pair:
( "kate-version"  |  "3.0" )
kwrite(3265)/Kate (Scripting) KateJScriptHelpers::parseScriptHeader: found pair:
( "functions"  |  "sorter" )

Comment 12 Kevin Kofler 2007-12-14 01:22:22 UTC
This time we're waiting for D-Bus, i.e. external input, which seems to make 
more sense to me than a thread waiting in QMutex when no other thread is 
running, but doesn't explain why we get no answer.

What's of course also possible is that the wait being interrupted in the 
backtrace isn't what takes forever, but only part of a much larger infinite 

Comment 13 Sebastian Vahl 2007-12-17 11:28:50 UTC
Mhh. With selinux disabled completely it seems to be working on my problematic 
installation and also on the livecds. On the f8-installation in comment #7 
selinux was already disabled.

Comment 14 Sebastian Vahl 2007-12-17 19:33:35 UTC
Created attachment 289798 [details]

After today's rawhide upgrade [1] the login is now possible also in permissive
mode. Because of comment #13 I had to relabel my filesystem. So I'm not sure if
this is working due to the relabeling or the update. A newly created livecd is
also working with enforcing=0

However, the audit.log is still full of avc denials, so I've attached this


Comment 15 Will Woods 2008-01-12 15:46:31 UTC
KDE4 has been updated significantly in recent days.. does this work now?

Comment 16 Sebastian Vahl 2008-01-12 17:06:22 UTC
(In reply to comment #15)
> KDE4 has been updated significantly in recent days.. does this work now?

Yes. It has been working for me since comment #14. I've not closed it because 
there were still much avc denials. But I have to re-check this.

Comment 17 Rex Dieter 2008-02-11 16:09:21 UTC
I'm of a mind to close *this* issue (since it is for all intents and purposes 
fixed), and then recommend that folks who find any new issues (including 
selinux avc denials), file new bugs.

Note You need to log in before you can comment on or make changes to this bug.