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): kdebase-3.97.0-1.fc9 kdebase-runtime-3.97.0-1.fc9 kdebase-workspace-3.97.0-2.fc9 kdebase-workspace-libs-3.97.0-2.fc9 kde-filesystem-4-4.fc9 kdelibs-3.97.0-6.fc9 kdepimlibs-3.97.0-2.fc9 kde-settings-4.0-4.fc9 kde-settings-kdm-4.0-4.fc9 How reproducible: ever Steps to Reproduce: 1. update to latest kde4 2. try to login or 2. start a different window manager and a terminal and try to launch some apps. 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.
Created attachment 285911 [details] output of "strace konsole"
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
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. :-(
PS: What I assume happened is that the other thread crashed/exited while holding the lock. :-(
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 openssl.
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?
(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.
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 OpenSolaris? http://people.fruitsalad.org/adridg/bobulate/index.php?/archives/494-Solaris-Close-....html http://people.fruitsalad.org/adridg/bobulate/index.php?/archives/495-Partial-KDE4-on-Solaris.html Sadly all these are just theories right now. :-(
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.
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.
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 0x9515170 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>" ) 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" ) [...]
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 loop.
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.
Created attachment 289798 [details] audit.log 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 file. libselinux-2.0.46-1.fc9 libselinux-python-2.0.46-1.fc9 selinux-policy-3.2.4-2.fc9 selinux-policy-targeted-3.2.4-2.fc9
KDE4 has been updated significantly in recent days.. does this work now?
(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.
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.