xorg-x11-libs-6.8.2-1.EL.13.25 After opening loads of xterms, or other X clients, we'd get the error: Xlib: connection to ":0.0" refused by server Xlib: Maximum number of clients reached xterm Xt error: Can't open display: sunultra20b:0.0 One way to reproduce is to run: for i in `seq 1 255`; do xlogo & done and see the ~240th instances and subsequent ones fail to connect to the display bug 176328 for RHEL3 isn't related, as it was about XOpenDisplay failing when the first fd would be >= 256. It isn't related to upstream: https://bugs.freedesktop.org/show_bug.cgi?id=2920 as the electricsheep screensaver isn't being used.
Created attachment 136545 [details] test.c
XIDs are the global namespace for objects in the X protocol. Clients are assigned a range when they connect, and subsequent allocations happen from that pool. The XID itself is allocated as follows: 3 bits reserved (for no good reason) N bits of client ID M bits of resource ID where N is defined by the MAXCLIENTS define in the server source. Which means right now, we have 8 bits for client ID and 21 for resource ID. This patch would move one bit to the client ID space, which has the side effect of reducing the number of resources per client from 2millionish to 1millionish. This is probably not a problem. However we may want to add an option somewhere to allow the user to switch this at server startup.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Built as xorg-x11 6.8.2-1.EL.25. MODIFIED.
Not fixed. Used the shell loop: for a in `seq 1 256`; do xlogo & done hit the limit at 253. I have some clients already opened. Starting a new one explicitly says the limit was hit.
*** This bug has been marked as a duplicate of 230217 ***