Bug 448846 - F9 KDE fails to start with BackingStore=true
F9 KDE fails to start with BackingStore=true
Status: CLOSED DUPLICATE of bug 457377
Product: Fedora
Classification: Fedora
Component: kdebase-workspace (Show other bugs)
9
All Linux
low Severity high
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-28 21:00 EDT by Vince Schiavoni
Modified: 2008-08-02 00:40 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-02 00:40:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Console output from manual attempt to startx/startkde (671.54 KB, application/octet-stream)
2008-05-28 21:00 EDT, Vince Schiavoni
no flags Details
/var/log/kdm.log timestamp 2008-06-01 14:49 375K (374.45 KB, application/octet-stream)
2008-06-01 14:53 EDT, Vince Schiavoni
no flags Details

  None (edit)
Description Vince Schiavoni 2008-05-28 21:00:40 EDT
Description of problem:
Note: I'm filing this bug against kdelibs because that package owns klauncher but if that ends up being 
wrong, please change it.

F9-KDE-LiveCD install, updated numerous packages from updates-testing, installed and removed 
numerous packages.  At some point, without warning, KDE failed to start from login screen.  Attempts 
to start from console yield attached output; fatal error seems to be related to klauncher and unknown 
application trying to embed in systray; relevant excerpt:

[...]
klauncher(30843)/kio (KLauncher) KLauncher::processRequestReturn: "/usr/bin/klipper" (pid 30893) up 
and running.
<unknown program name>(30894)/ kdemain: Xlib XKB extension major= 1  minor= 0
plasma(30861) SystemTrayContainer::SystemTrayContainer: attempting to embed 4194307

Backtrace:
0: X(xf86SigHandler+0x79) [0x80d60c9]
1: [0x110400]
2: X(miHandleValidateExposures+0x37) [0x8127b07]
3: X(UnmapWindow+0x1f8) [0x8070368]
4: X(compFreeClientWindow+0x2d3) [0x8143e63]
5: X [0x813f914]
6: X(FreeResource+0x10c) [0x806db6c]
7: X(compUnredirectWindow+0x8b) [0x814322b]
8: X [0x814016c]
9: X [0x8128125]
10: X [0x812803c]
11: X(miChangeSaveUnder+0x6b) [0x81281db]
12: X(MapWindow+0x37b) [0x8070acb]
13: X(ProcMapWindow+0x69) [0x80851b9]
14: X(Dispatch+0x34f) [0x8085a3f]
15: X(main+0x47d) [0x806b3bd]
16: /lib/libc.so.6(__libc_start_main+0xe6) [0x4e05d6]
17: X(FontFileCompleteXLFD+0x22d) [0x806a7a1]

Fatal server error:
Caught signal 11.  Server aborting

klauncher(30843)/kio (KLauncher) KLauncher::processRequestReturn: "/usr/bin/ksensors" (pid 30896) 
up and running.
kerneloops-applet: Fatal IO error 104 (Connection reset by peer) on X server :0.0.
kdeinit4: Fatal IO error: client killed
kdeinit4: sending SIGHUP to children.
klauncher: Exiting on signal 1
kdeinit4: sending SIGTERM to children.
kdeinit4: Exit.
xinit:  connection to X server lost.
Hangup
[...]

Attempted to manually back-off updates and remove packages that were installed, but no joy.  Google 
and bugzilla searches find nothing.

Version-Release number of selected component (if applicable):
F9-KDE-LiveCD install
kernel-2.6.25.3-18.fc9.i686

How reproducible:
Always.

Steps to Reproduce:
1. Install F9-KDE-LiveCD
2. Update to all latest testing packages
3. Logout, attempt login.
  
Actual results:
KDE crash on login.

Expected results:
Successful login.

Additional info:
On request.
Comment 1 Vince Schiavoni 2008-05-28 21:00:40 EDT
Created attachment 307004 [details]
Console output from manual attempt to startx/startkde
Comment 2 Rex Dieter 2008-05-28 21:45:29 EDT

1.  Does problem exist for all users on this box, or just 1 in particular?

Please try:
2.
$yum groupinstall kde-desktop

does problem still occur?  if so,

3.
$yum install yum-utils
$package-cleanup --problems

please report output.



Comment 3 Vince Schiavoni 2008-05-29 03:49:31 EDT
Hello:

1. All users: already tried as root user, same results; tried just now with new 
user, same results; also tried (re)moving ~/.kde, .dbus, and .config, same 
results. Also tried with boot parameter 'selinux=off' (was: permissive), no 
help.

2. OK, with fedora, updates, and updates-testing repos enabled (had to enable 
updates-testing due to dependency requirements caused by prior updates/
installs), ran 'yum groupinstall "KDE (K Desktop Environment)": 35 packages in 
transaction - 4 updated, 31 installed (excerpt from yum.log attached). Then: 
startx, results same for all users including root.  Tried 'mv ~/.kde ~/.kde-
bku', startx, results: hard system lock-up, no recovery possible, required hard 
re-set. Re-booted, tried to graphical log in again, results: same (KDE crash 
near end of desktop start-up sequence).

Next, tried from console login: 'yum groupremove "KDE (K Desktop Environment)"; 
49 packages were removed; a whole huge pile of updates and add-ons had to be 
removed also before I could try again: 'yum groupinstall "KDE (K Desktop 
Environment)" BUT with only a custom-made temporary repo enabled using 
mirrors.kernel.org as the "base" install (probably should have just re-
installed the whole OS, but then how would we find the problem?); results: same 
(KDE crash). Added another new user, same results. Checked again for --dupes 
and --problems - none. At this point, I took an inventory of all non-Fedora/Red 
Hat packages installed, and began to remove them, starting with ones that 
seemed likely to cause the problems. Gave up, installed E17 from kriehn repo, 
will continue to try to diagnose later from working graphical interface. Other 
suggestions welcome.

3. Already tried (repeatedly), also: 'package-cleanup --dupes' - no problems, 
no dupes, never, not once.  Also repeatedly ran 'updatedb' just in case....

Thanx and Regards,
VJS
Comment 4 Vince Schiavoni 2008-05-29 12:27:25 EDT
Hello:

Update: just to make it clear, E17 DE installed from 3rd-party repo is up and 
running just fine, so I have to believe that one of the (many) recent updates/
installs caused this problem.  Also: when KDE was up and running, ~/.xsession-
errors was at one point at 1.6 GB size. !?

That's 1.6 GB !!!

That's a text file - I didn't attempt to review it....

Currently: ~/.xsession-errors=329 kB after uptime=8.5 hours (E17).

Thanx and Regards,
VJS
Comment 5 Vince Schiavoni 2008-06-01 11:29:42 EDT
Hello:

At this point, I've got the non-Fedora/Livna/FreshRPMS/ATRPMs/KDE-RedHat/kriehn 
packages trimmed to:

aim
checkinstall
cpuid
jre
libdrm (custom built from source code)
libdrm-devel (ditto)
opera
Q7Z
usermin
webmin
xorg-x11-drv-nouveau (custom built from source code)
xorg-x11-drv-nv (ditto)
ymessenger

Not all of which were installed at the time problems started. Hope that info 
helps.

Regards,
VJS
Comment 6 Rex Dieter 2008-06-01 12:40:45 EDT
Please revert to stock fedora versions of libdrm, and your x11-drv in use, else
we'll not have much choice to lay blame there (on items not verifiable or
confirmable outside of yourself and your box).
Comment 7 Vince Schiavoni 2008-06-01 14:53:03 EDT
Created attachment 307317 [details]
/var/log/kdm.log timestamp 2008-06-01 14:49 375K
Comment 8 Vince Schiavoni 2008-06-01 14:54:54 EDT
Alright, then:
libdrm-2.4.0-0.11.fc9.i386 (fedora)
libdrm-devel-2.4.0-0.11.fc9.i386 (fedora)
xorg-x11-drv-nv-2.1.8-1.fc9.i386 (fedora)
xorg-x11-drv-nouveau-0.0.10-2.20080408git0991281.fc9.i386 (fedora)

Also removed all proprietary nvidia driver packages from ATRPMs (which didn't 
work anyhow). If I should erase anything else to isolate this issue, I'll be 
happy to do so if asked.

BTW, none of the above were installed prior to 5-29-2008 (the day after 
problems started, which is why I tried with video drivers compiled by myself).

No change - cannot start KDE. 'package-cleanup --dupes[--problems]' continue to 
return nothing but blanks. 'rpm -Va' shows only the usual/expected outout. I'm 
attaching /var/log/kdm.log which goes all the way back to install date 
5-26-2008. Not sure what to make of it....

Regards,
VJS
Comment 9 Rex Dieter 2008-06-01 15:05:57 EDT
Could you consider using the f9 kde live iamge?  This would determine more
conclusively if it's a fundamental problem with f9/kde4 or your box.
Comment 10 Vince Schiavoni 2008-06-02 13:36:54 EDT
I'm a little disappointed that I didn't think to try that....

OK, booted the F9-KDE-LiveCD. Removed pulseaudio suite (doesn't work, fries 
speakers, floods ~/.xsession-errors), also some extraneous misc. gnomic tools 
and wireless drivers, etc. (same as before), setup display/xorg.conf, then 
proceded to update packages in small chunks, logging out of desktop and re-
starting X-server in between. Got all the way through the alphabet, 
unfortunately that's all the farther I got: plenty of RAM and SWAP, but I guess 
this CPU can't handle any more work without installing - basically, the GUI 
ground to a halt, due to slow CPU.

However, I found this in /var/log/messages:
[...]
Jun  2 03:16:04 micron-pc-rb kernel: klauncher[7698]: segfault at 8048814 ip 
00a69da8 sp bfbb9200 error 7 in libX11.so.6.2.0[a54000+fd000]
Jun  2 03:16:04 micron-pc-rb kdm[3732]: X server for display :0 terminated 
unexpectedly
Jun  2 03:16:04 micron-pc-rb acpid: client connected from 7756[0:0]
Jun  2 03:25:10 micron-pc-rb hddtemp[3239]: /dev/sda: WDC WD800JB-00JJC0: 102 F
Jun  2 03:25:10 micron-pc-rb hddtemp[3239]: /dev/sdb: WDC WD1600AAJB-00PVA0: 
109 F
Jun  2 03:32:01 micron-pc-rb ntpd[3115]: synchronized to 138.23.180.126, 
stratum 2
Jun  2 03:55:37 micron-pc-rb ntpd[3115]: synchronized to 217.160.254.116, 
stratum 2
Jun  2 04:25:10 micron-pc-rb hddtemp[3239]: /dev/sda: WDC WD800JB-00JJC0: 102 F
Jun  2 04:25:10 micron-pc-rb hddtemp[3239]: /dev/sdb: WDC WD1600AAJB-00PVA0: 
107 F
Jun  2 04:34:56 micron-pc-rb kernel: prelink[836]: segfault at a81 ip 0806a61f 
sp bfae6ec0 error 4 in prelink[8048000+107000]
[...]
There are many dozens more of the klauncher segfault errors logged since 
install, all the same except for PID number. libX11.so.6.2.0 (package 
libX11-1.1.4-1.fc9.i386) has not been altered in any way since install.

BTW, I had also re-installed mesa-libGL (which had been replaced with the other 
Xorg stuff). Also FYI, the re-build Xorg stuff worked fine, it just didn't help 
with the KDE problem.

Hope this helps.

Thanx and Regards,
VJS
Comment 11 Vince Schiavoni 2008-06-30 01:14:10 EDT
OK, I finally got the second install of F9 to boot (turns out that it was an 
update to F8 GRUB dealing with "Inode size" that was the problem). Now I have 
_two_ extra F9 OS installs to test with (total of [3] F9's on that machine). 
The second F9 OS started a KDE session without any issues that I can see. I did 
also notice that ~/.xsession-errors is already quite large.

Both of these two extra F9 installs are completely new and clean at the moment. 
I'm going to start updating packages on the first one. Any suggestions as to 
what else to try ? Anything in particular I should do / not do or look at ?

Regards,
VJS
Comment 12 Vince Schiavoni 2008-07-12 11:56:37 EDT
Got it !

It's the 'nouveau' video driver (xorg-x11-drv-nouveau). Use 'nouveau', and KDE 
crashes - the farthest I got was to an active, loaded KDE desktop, but as soon 
as I tried to select anything with the mouse, bang! Crash, right back to the 
login screen - which also crashed if I tried to use the menus there: only 
typing the password and hit <Enter> actually did something besides cause a lock-
up and re-start X. Also, could not switch to a VT from the login screen - 
locked up on all six VTs, but VT7 was still alive and OK (I could press ALT-CTL-
F7 and get back a live login screen). Same results for all (3) users. I 
actually had to boot into the other OS and change xorg.conf there. Switched the 
driver back to 'nv', and now all is well.

Still doesn't explain why the first F9 OS is still screwed up, because I've 
tried other video drivers on it too. Whatever happened to the first F9 install 
must have done a good job of messing things up. Nor does it explain why 
Enlightenment/E17 is immune to the 'nouveau' effect.

Must not be many people using 'nouveau' on F9, or I would think there would be 
more reports of this....

Of course, I can't prove definitively that it is in fact 'nouveau', but the 
results of these attempts to track this down sure look make it look like that's 
the culprit.

Regards,
VJS
Comment 13 Vince Schiavoni 2008-07-25 19:56:30 EDT
And the clue to solving the final piece of the puzzle came from this thread: 
http://forums.fedoraforum.org/forum/showthread.php?t=195131

The Culprit (in this case): xorg.conf 'Option "BackingStore" "true" '

Using the 'nv' video driver without "BackingStore" on allows KDE4 to 
succesfully launch a desktop session. All F9-KDE-Live OS installs now start KDE 
desktop sessions successfully, including the first one that hasn't worked now 
for almost two months....

"Warp power has been restored, Captain!"

Which leaves the questions unanswered:
> Why does video driver 'nouveau' cause KDE4 to lock-up/crash?
> Why does Xorg option "BackingStore" on cause KDE4 to lock-up/crash?

All other DEs/Window Managers are immune to these two phenomenon.

Since a root cause and solution have been found (as far as I'm concerned), I'll 
be removing the extra F9-KDE-Live OS installs very shortly, unless someone 
needs more info (and gets back to me before I nuke them).

Thanx and Regards,
VJS
Comment 14 Rex Dieter 2008-08-02 00:40:25 EDT
Glad to hear it.

The BackingStore issue is likely an X server problem.

*** This bug has been marked as a duplicate of 457377 ***

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