Bug 422061

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.