Bug 651694 - [abrt] gmixer-1.3-17.fc14: display.py:120:__init__:DisplayConnectionError: Can't connect to display ":0.0": Maximum number of clients reached
Summary: [abrt] gmixer-1.3-17.fc14: display.py:120:__init__:DisplayConnectionError: Ca...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gmixer
Version: 14
Hardware: i686
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Orphan Owner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:70ec8fc6
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-10 06:26 UTC by Kerry
Modified: 2012-08-16 18:08 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 18:08:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: backtrace (1.35 KB, text/plain)
2010-11-10 06:26 UTC, Kerry
no flags Details
Output from xwininfo and xrestop commands (18.39 KB, application/zip)
2010-12-13 10:34 UTC, Kerry
no flags Details
rpm -qa |sort (26.83 KB, application/zip)
2010-12-13 19:33 UTC, Kerry
no flags Details

Description Kerry 2010-11-10 06:26:41 UTC
abrt version: 1.1.13
architecture: i686
cmdline: /usr/bin/python -OO /usr/bin/gmixer -d
component: gmixer
executable: /usr/bin/gmixer
kernel: 2.6.35.6-48.fc14.i686.PAE
package: gmixer-1.3-17.fc14
reason: display.py:120:__init__:DisplayConnectionError: Can't connect to display ":0.0": Maximum number of clients reached
release: Fedora release 14 (Laughlin)
time: 1289366985
uid: 500

backtrace
-----
display.py:120:__init__:DisplayConnectionError: Can't connect to display ":0.0": Maximum number of clients reached

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/gtktrayicon.py", line 98, in reconnect_dock
    if self.update_manager_window(False):
  File "/usr/lib/python2.7/site-packages/gtktrayicon.py", line 167, in update_manager_window
    xdisplay = self.get_xdisplay()
  File "/usr/lib/python2.7/site-packages/gtktrayicon.py", line 161, in get_xdisplay
    xdisplay =  Xdisplay.Display(name)
  File "/usr/lib/python2.7/site-packages/Xlib/display.py", line 83, in __init__
    self.display = _BaseDisplay(display)
  File "/usr/lib/python2.7/site-packages/Xlib/display.py", line 65, in __init__
    apply(protocol.display.Display.__init__, (self, ) + args, keys)
  File "/usr/lib/python2.7/site-packages/Xlib/protocol/display.py", line 120, in __init__
    raise error.DisplayConnectionError(self.display_name, r.reason)
DisplayConnectionError: Can't connect to display ":0.0": Maximum number of clients reached

Local variables in innermost frame:
name: ':0.0'
displayno: 0
self: <Xlib.display._BaseDisplay instance at 0x124a9a8c>
display: ':0.0'
auth_data: '\xd1\xca\x82Z\x18\x8e\xc6\xb0\x85S|\x17{\xa9YQ'
auth_name: 'MIT-MAGIC-COOKIE-1'
host: ''
r: <Xlib.protocol.display.ConnectionSetupRequest instance at 0x124bbdac>
screenno: 0
order: 108

Comment 1 Kerry 2010-11-10 06:26:44 UTC
Created attachment 459324 [details]
File: backtrace

Comment 2 flashl 2010-12-07 11:00:05 UTC
Package: gmixer-1.3-17.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. Log out
2. Leave Login screen idle for several hours
3. Log in

Comment 3 Thomas Spura 2010-12-07 11:33:25 UTC
According to [1], you can run 'xrestop' to see, what package uses the most connections to the x server. So maybe one is only requesting connections, but never closes them...


[1] http://forums.gentoo.org/viewtopic-t-660860.html

Comment 4 Terry Wallwork 2010-12-09 15:13:01 UTC
Package: gmixer-1.3-17.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. Unknown
2.
3.

Comment 5 Kerry 2010-12-10 02:30:11 UTC
I've had to abandon Gnome on my desktop because of this error. I am unable to run Gnome for more than a few hours before things start crashing and I'm unable to start any new applications. 

Switching to KDE avoids the problem, but isn't a solution. My guess is there is some sort of resource leak in one of the Gnome libraries or applications which isn't closing connections after it uses them.

Another related bug is
https://bugzilla.redhat.com/show_bug.cgi?id=657120

Comment 6 Thomas Spura 2010-12-10 07:15:46 UTC
Kerry, could you please try to find the package, which uses the most connections to the x server?
That program (or at least on in the top3) is requsting more and more x connections without closing them...

Comment 7 Kerry 2010-12-13 10:33:12 UTC
I switched back to Gnome and after a few hours I got more crashes
https://bugzilla.redhat.com/show_bug.cgi?id=657120
https://bugzilla.redhat.com/show_bug.cgi?id=662595

I let a script run every few minutes to check on what resources are being used. (If this isn't useful information, let me know what would be more appropriate to track down this problem.)
$ cat ~/bin/wininfo.sh
DATE=`date`
xrestop -d 0:0 -b -m 1 > /tmp/winlog/xrestop$DATE.txt
xwininfo -d 0:0 -children -root  > /tmp/winlog/wininfo_$DATE.txt

I've attached a few log files (xrestop.zip). 19:00 was about an hour before things started crashing. I had gone out, so nothing new should have been started or stopped during that time.
$ ls
early.txt
late.txt
wininfo_Mon Dec 13 19:00:01 EST 2010.txt
wininfo_Mon Dec 13 19:56:01 EST 2010.txt
xrestopMon Dec 13 19:00:01 EST 2010.txt
xrestopMon Dec 13 19:56:01 EST 2010.txt

Things started crashing about 20:00, so 19:56 is the last things would have run correctly. After that, the xwininfo command is unable to start because of the max number of clients problem.

The early.txt and late.txt files are just the process name and number of windows with everything stripped out from the xrestop output. Nothing really seems to be different between them with the applications running or the number of windows they use. 

What is different is there are lots of items like:

229 - <unknown> ( PID:  ?   ):
	res_base      : ox6c00000
	res_mask      : ox1fffff
	windows       : 0
	GCs           : 0
	fonts         : 0
	pixmaps       : 0
	pictures      : 0
	glyphsets     : 0
	colormaps     : 0
	passive grabs : 0
	cursors       : 0
	unknowns      : 0
	pixmap bytes  : 0
	other bytes   : ~0
	total bytes   : ~0

Any ideas how to figure out what they are?

Comment 8 Kerry 2010-12-13 10:34:12 UTC
Created attachment 468335 [details]
Output from xwininfo and xrestop commands

Comment 9 Thomas Spura 2010-12-13 11:05:03 UTC
(In reply to comment #7)
> 
> Any ideas how to figure out what they are?

Not really, sorry...

In bug #657120 you guess, that it's gnome-packagekits fault. Maybe you could try the same, when you deinstall PackageKit* completely?

Or do you know, when this started, so you could search for packages, which could introduce this?

If you can't, maybe 'rpm -qa | sort' would be usefull, sometime (don't konw...).

Comment 10 Kerry 2010-12-13 19:32:21 UTC
At one point I did deinstall gnome-packagekit and it didn't make any difference. 

I know exactly when it started, immediately after the upgrade to Fedora 14. Lots of packages changed then, so I'm not sure exactly which one might be at fault.

Attached a list of rpms.

Comment 11 Kerry 2010-12-13 19:33:05 UTC
Created attachment 468462 [details]
rpm -qa |sort

Comment 12 Terry Wallwork 2011-02-24 16:46:31 UTC
Package: gmixer-1.3-17.fc14
Architecture: i686
OS Release: Fedora release 14 (Laughlin)


How to reproduce
-----
1. ran centerim client
2.
3.

Comment 13 Fedora End Of Life 2012-08-16 18:08:20 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


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