easy way to reproduce this:

for i in `seq 1 255` ; do
    xlogo &
done

this is pretty unacceptable.  we can bump this to 512 in the short term.  the
right fix is making the connection table dynamic, which will require surgery to
other parts of the code like resource ID generation.

The protocol requires at least 18 contiguous bits in the resource-id-mask, and
it requires that the top three bits are not used. That leaves us with only 12
bits to distinguish clients, so 4096 clients seems like a hard limit to me

well, 2048 actually, since 32 - 3 - 18 = 11.

only if you insist on encoding the client's connection number in the resource
ID; technically we can just give the client the whole 29-bit space and maintain
a mapping from (res id, client) -> (resource) on the server side.

XID's have to be unique across clients. QueryTree is one thing that would break,
but there are many other examples. 

In Xsun, we didn't remove the limit, but did make it more dynamic by adding a
runtime flag to choose between a limit of 128 clients, with lots of available
resource ids per client, and 1024 clients, with fewer available resource ids,
and in Solaris 9 and later, set the default to 1024 clients.   A very small 
number of very resource hungry clients hit the smaller limit, but not many.

In my case the problem isn't the 255 limit. On a fresh login I use ~18 and ~30
seems be enough to fill my needs.

The problem is that just leaving the computer on, not tuching it, produces some
kind of leakage. Changing the limit to 512 would only buy me about 3 days of
uptime. 

(In reply to comment #7)
> The problem is that just leaving the computer on, not tuching it, produces some
> kind of leakage. Changing the limit to 512 would only buy me about 3 days of
> uptime. 

this is almost certainly due to a leaking application rather than a leaking
server.  just to check, next time this happens run 'lsof -U' as root and attach
the output here.

The other thing to keep in mind is while it reports as a number of clients limit,
it's actually, due to the current implementation, a limit on the id of the file
descriptors, so you can hit it with only one other client open if somehow the X
server also has all file descriptors up to 255 in use for something else (perhaps
shared memory segments, a fd leak in one of the system libraries, like the name
resolver, etc.)

I think the cygwin guys recently solved this for their code by changing the client
id from being just the fd to using a hash table to map it to the fd.

Created attachment 2358 [details]
xrestop -b

Created attachment 2359 [details]
lsof -U

Someone hinted that this might be due to some faulty TreuType fonts. Is that
possible?

I have no scientific evidence of this, but I am conviced that xscreensaver,
possibly combined with electricsheep, is the cause of this bug. After disabling
xscreensaver (killall -9 xscreensaver) upon starting X I no longer experiance
these "zombie clients". 

My box has only been up for three days. However that is about how long it took
to reach the 255 client limit previously. I will update this bug report again in
a few days if I can confirm that xscreensaver is indeed causing the problem.

Please let me know if there is any other information that may be helpful.

At the time that I reported this bug, I belive that I was using electricsheep
also. So it is plausible.

Well, I think we may have a test case here. I turned xscreensaver back on and
let my box sit here for ~8 hours. Now there are ~80 zombie clients. Before there
were little or no zombie clients. The screensaver I am using is electricsheep
2.6.2 for xscreensaver 4.20.

Can anyone else confirm this? 

I am going to try switching the screensaver from electricsheep to something less
intense to see if it is X, or electricsheep that is causing the problem

I have changed my screensaver to one that is installed per default and I am no
longer leaking sessions. I am about 99% sure that this is a problem with
electricsheep and  has nothing to do w/ X.

If anyone else can confirm this maybe this bug should be resolved?

Debian bug #325689 confirms that electricsheep is buggy.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325689

electricsheep bug, not ours.