Bug 575362 - KDE 4.4.x reaches too easily maximum number of X clients
KDE 4.4.x reaches too easily maximum number of X clients
Product: Fedora
Classification: Fedora
Component: qt (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-03-20 07:43 EDT by Davide Rondini
Modified: 2010-12-03 12:01 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-12-03 12:01:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output of xwininfo -root -children during work session (63.70 KB, text/plain)
2010-03-20 10:41 EDT, Davide Rondini
no flags Details
Output of xlsclients during work session (17.25 KB, application/octet-stream)
2010-03-20 10:42 EDT, Davide Rondini
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 230425 None None None Never

  None (edit)
Description Davide Rondini 2010-03-20 07:43:04 EDT
Description of problem:
Since I updated to latest KDE 4.4.x and xorg, after opening a few applications, the maximum limit of X11 clients is reached, and it is not possible to open other windows, unless some one of the already opened windows is closed.

I reported this bug in KDE butracking, but it looks like this manifests clearly in latest Fedora, and maybe it is not (only) related to KDE (maybe a KDE-xorg interaction?):


In the KDE bug I filed the output of some x11 diagnostic commands.

Version-Release number of selected component (if applicable):
KDE 4.4.*

How reproducible:

Steps to Reproduce:
1. Install latest Fedora 12 updates with KDE 4.4.x and xorg 1.7.6 RC
2. Login into KDE
3. Open 7-8 apps
Actual results:
Cannot open further windows, even though the number of opened windows is very limited

Expected results:
Open a large number of windows.

Additional info:
Comment 1 Rex Dieter 2010-03-20 07:54:40 EDT
This *usually* indicates a misbehaving application (or 2).  Which apps do you generally run?

(In particular, some recent versions of google chrome are known bad in this regard)
Comment 2 Rex Dieter 2010-03-20 07:56:07 EDT
is a good tool to help debug here.
Comment 3 Davide Rondini 2010-03-20 10:39:27 EDT
I've installed Google Chrome, but I use it very rarely, and surely I can reproduce the bug without launching it.

I usually use KDE apps (that's why I started reporting the bug to KDE bug tracking). I've just reconstructed a session reproducing the bug starting some apps which I usually use and tracking the output of commands xlsclients and xwininfo -root -children between every application launch (see attachments). I followed this procedure, with the numbers between parentheses respectively the output of the commands:

1: xlsclients | wc -l
2: xwininfo -root -children | wc -l

0. Boot
1. Login into KDE (this automatically activates yakuake, nm-applet, kopete and kmix) (67/106)
2. Launch kontact (93/146)
3. Launch Firefox (94/157)
4. Launch Dolphin (97/163)
5. Launch Kate    (103/171)
6. Launch Okular  (106/176)
7. Launch Konqueror

When trying to launch Konqueror, the app did not start. Then I tried to launch it from yakuake console, and it started, but at that point the x commands respond:

Maximum number of clients reachedxwininfo:  unable to open display ':0'

The real number of apps opened may vary, but anyway after 7-8 windows the problem appears every time.

I've reproduced the bug on three different machines with Fedora 12, both with nvidia proprietary and Intel video drivers.

While the problem do not manifest using gnome, I guess this may be related to Qt or kdelibs.
Comment 4 Davide Rondini 2010-03-20 10:41:01 EDT
Created attachment 401447 [details]
Output of xwininfo -root -children during work session
Comment 5 Davide Rondini 2010-03-20 10:42:16 EDT
Created attachment 401448 [details]
Output of xlsclients during work session
Comment 6 Steven M. Parrish 2010-03-28 18:32:11 EDT
Thank you for taking the time to report this issue to us.  This is an issue which is best addressed by the upstream developers.

Please file a report at bugs.kde.org , and when done add the upstream report info to this report.

We will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates.

Thank you for the bug report.

Steven M. Parrish
KDE & Packagekit Triager 
Fedora Bugzappers volunteer triage team
Comment 7 Diego 2010-04-03 07:51:20 EDT
This is already tracked as "CLOSED -> UPSTREAM" on bugs.kde.org:

It's a Qt bug, but A.Seigo wonders why the number of possible connections is so low:
«QGraphicsProxyWidget only accepts top-level widgets for embedding. Top-level
widgets are created as native windows. QGraphicsProxyWidget does nothing to
prevent this from happening, an so every QGraphicsProxyWidget results in a
client window being created.

this is obviously sub-optimal and unnecessary.

btw, i wonder why the allowed connection # is so low on your system. 135 is
really quite low.»

Could there be something wrong in xserver too?
Comment 8 Rex Dieter 2010-04-06 14:06:23 EDT
See also,
Comment 9 Davide Rondini 2010-07-26 06:05:24 EDT
After recent updates the bug seems to be disappeared: I've tested the system for a while and never experienced the problem any more. I'm not really sure about which update fixed the bug, but if no one else can still reproduce it, I propose to close it.
Comment 10 Kevin Kofler 2010-07-26 06:13:01 EDT
Maybe Qt 4.6.3?
Comment 11 Davide Rondini 2010-07-26 08:25:42 EDT
Taking a look to my yum history, I see that I installed Qt 4.6.3 on July 14th. As far as I remember, the bug was already solved two weeks ago, I was already testing if everything worked fine. Going back into update history, previous update I did of Qt was June 17th, from 4.6.2-17 to 4.6.2-20. This is more likely to be the fixing update.
Comment 12 Bug Zapper 2010-11-03 15:06:32 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 13 Bug Zapper 2010-12-03 12:01:50 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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