Red Hat Bugzilla – Bug 70706
QT applications crash in "Render-less" XDMCP servers
Last modified: 2007-04-18 12:45:12 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020721
Description of problem:
First of all, I wasn't really sure if I had to file this bug against KDE,
XFree86 or gdm. I chose gdm because of the XDMCP issues involved.
I have a machine running Red Hat Linux 7.3.93 (Limbo 2) which - aside from
most of the bugs reported in Bugzilla - is running fine (locally / me sitting
on the chair behind that Linux PC).
I also have a PC running Microsoft Windows with Reflection X.
On the PC running Limbo beta 2, I configured gdm to listen to X connections.
On the PC running Windows & Reflection X I do a XDMCP connection with a XDMCP
Broadcast. This works fine, and gdm presents itself to me on Windows on my
Reflection X Root Window.
When I select "Gnome" from 'Session' at the bottom of the screen and log in
with my username & password, Gnome starts up (although it gives an error
concerning /dev/sound/mixer. Apart from this error of the sound daemon
Gnome seems to work ok.
OK, _but_ when I select "KDE" from 'session' at the bottom of the screen and
log in with my username / password, KDE starts up but crashes at a certain
point with a message about /dev/dsp (error goes offscreen really fast) and
gives a unreadable 'artsmessage' pop-up.
I made some screenshots where you can show for yourself. :-)
At first I thought it was a soundcard module issue, because when I start KDE
from gdm _locally_ the following modules are automatically loaded by KDE :
- i810_audio 24712 1 (autoclean)
- ac97_codec 13320 0 (autoclean) [i810_audio]
- soundcore 6500 2 (autoclean) [i810_audio]
Then I rebooted the Linux box and tried starting KDE from gdm remotely with
XDMCP by using Reflection X on Windows. This time KDE did not automatically
loaded the necessary soundcard modules.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Setup gdm so it listens to XDMCP connections.
2. Use Reflection X on a Windows PC to connect to the Linux box.
Gnome is able to start - but with a warning / error about "/dev/sound/mixer".
Gnome seems fine apart from this error.
KDE crashes after trying to start - with a error about "/dev/dsp" (..I think,
the error disapppears quite fast). KDE does not repond to mouse clicks and the
X Client on the Windows PC has to be restarted.
Both Gnome and KDE should work fine just as if they were started locally /
me sitting on a chair (behind / in front of) the Linux box.
[root@limbo-pc root]# rpm -qa |grep -i xfre
[root@limbo-pc root]# rpm -qa |grep -i gdm
[root@limbo-pc root]# rpm -qa |grep -i kdeba
Created attachment 68807 [details]
gdm shows itself to Reflection X
Created attachment 68808 [details]
Gnome error just after starting Gnome from gdm
Created attachment 68809 [details]
KDE crash just after starting KDE from gdm
I would initially guess that this is a KDE issue. Thanks for the detailed report.
I have seen several KDE startup crashes in Limbo due to sound device related
errors, even when running KDE on a standalone machine. If you agree that this
is possibly a KDE sound issue, please rename the short summary in order to more
easily identify this bug.
Hmm. I thought about this for a while.
Warren : You're right... KDE relies on the presence of the soundcard modules too
I'll rename the short summary of this bug entry to something more appropriate.
I may also be wrong in this diagnosis, but this is what I suspected after seeing
KDE crash on machines like nForce without sound drivers properly configured.
I would also recommend high priority, high severity because this is a killer
showstopper for LTSP.
This evening I tried to find out some more of this bug.
I think there are at least two major kind of issues with KDE in Limbo beta 2.
- Sound dependency (no soundcard / driver --> no KDE).
- XDMCP issues (strange crashes).
(I really hope XDMCP eventually works as it should, because it is ideal to let
people play with Linux in a company where X clients are used).
This evening I loaded KDE locally on the machine, which caused the necessary
sound modules to be 'modprobed' automatically by artsd.
I then exited KDE locally so I saw gdm again.
(I went to CTRL-ALT-F1 to make sure the sound-modules were still loaded).
So I went to my Windows machine with Reflection X and tried starting KDE from
gdm. After a few seconds KDE's icons began to show on screen - this time without
an error from arts about "/dev/dsp" missing - and I really thought that this
time it worked ('it' being a workable KDE session with XDMCP).
But, alas, as soon as I clicked on the "K" button on the bottom left of the
screen, the KDE Kicker crashed, showing only the KDE icons on the desktop.
After maybe 10 seconds, also the icons disappeared leaving me alone with an
empty KDE desktop.
I made some screenshots to illustrate what I just said.
(I do not experience this kind of behaviour of KDE when using the machine
Perhaps it would be wise to make some separate bugreports of this issue.
Is there anyone who can reproduce this problem by using Reflection X - or
another X client - for Windows?
(I haven't tried "Linux box X" XDMCP to "Linux box Y" XDMCP, though).
Created attachment 69005 [details]
At this time everything seems OK
Created attachment 69006 [details]
.. but after clicking on the "K" this happens
Created attachment 69007 [details]
Eventually also the icons disappear
I can't reproduce this with Linux -> Linux (I do get the message, but it's
readable (you don't have permissions to access /dev/dsp), and goes away when I
click it), so this looks like a bug in Reflection.
Can you reproduce this with anything else?
I must apologize, I somehow mistook a system crash (unrelated sound driver bugs,
triggered during KDE startup) for a KDE crash. This bug may be entirely XDMCP
related. I will continue to test both XDMCP and sound tomorrow.
Bero, out of curiosity does it still work properly with XRENDER disabled on the
X -query side?
Played, re-thought and experimented a bit more...
I was trying to reproduce a LICQ bug and by coincidence I started LICQ
from the command-line in a Gnome session (started from GDM in Reflection X).
After typing in "licq", the following output appeared :
20:07:56: [WRN] Licq: Ignoring stale lockfile (pid 8082)
Xlib: extension "RENDER" missing on display "10.0.0.4:0.0".
Xlib: extension "RENDER" missing on display "10.0.0.4:0.0".
Licq Segmentation Violation Detected.
Attempting to generate core file.
So, it also seems LICQ needs the RENDER extension.
Probably all QT stuff requires the RENDER extension.
If a 'RENDER complient' X server cannot be found, the application crashes.
My guess that the same is happening in KDE starting from gdm in a
Reflection X session.
But because that session didn't give any useful output, I never thought
of the RENDER extension.
Bero, can you do a Linux XDMCP <-> Linux XDMCP test using e.g.
Red Hat Linux 6.2 to connect to Red Hat Linux 7.3.93?
I think Red Hat Linux 6.2 doesn't have a RENDER extension in the X server.
So also that probably will trigger the bug.
I'll rename the short summary to something more appropriate.
A lot of X servers don't have the 'RENDER extension'.
Main question is... Are these people ruled out of using KDE 3.02
remotely with Red Hat 7.3.93?
Problem still exists in Red Hat Linux 7.3.94 ('null').
It seems that Red Hat Linux release 9 (Shrike) contains changes that fixes this
problem for me. Those changes probably are in the QT library; I've successfully
started both Licq from a XDMCP Gnome session via Reflection for Windows and KDE
itself from a XDMP session via Reflection.
- Changing component from "kdebase" to "qt".
- I'll close this bug with resolution "CURRENTRELEASE".
(probably fixed somewhere in the upstream package).