Bug 422061 - KDE4 applications aren't starting at all
KDE4 applications aren't starting at all
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kdebase (Show other bugs)
rawhide
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
HotIssue
:
Depends On:
Blocks: KDE4Live
  Show dependency treegraph
 
Reported: 2007-12-12 12:25 EST by Sebastian Vahl
Modified: 2008-02-11 11:09 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-11 11:09:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Sebastian Vahl 2007-12-12 12:25:12 EST
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.
Comment 1 Sebastian Vahl 2007-12-12 12:26:52 EST
Created attachment 285911 [details]
output of "strace konsole"
Comment 2 Sebastian Vahl 2007-12-12 12:29:17 EST
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 12:34:03 EST
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 12:35:28 EST
PS: What I assume happened is that the other thread crashed/exited while 
holding the lock. :-(
Comment 5 Sebastian Vahl 2007-12-12 18:19:10 EST
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.
Comment 6 Ngo Than 2007-12-13 05:03:36 EST
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 08:45:52 EST
(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 11:30:00 EST
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. :-(
Comment 9 Sebastian Vahl 2007-12-13 17:49:01 EST
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 18:43:38 EST
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-13 19:29:54 EST
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@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-13 20:22:22 EST
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.
Comment 13 Sebastian Vahl 2007-12-17 06:28:50 EST
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 14:33:35 EST
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
Comment 15 Will Woods 2008-01-12 10:46:31 EST
KDE4 has been updated significantly in recent days.. does this work now?
Comment 16 Sebastian Vahl 2008-01-12 12:06:22 EST
(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 11:09:21 EST
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.