Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Equinix is shutting down its operations with us on April 30, 2025. They have graciously supported us for almost 5 years, but all good things come to an end. We are expecting to transition to new infrastructure between late March and mid-April. We do not yet have a firm timeline for this, but it will involve (probably multiple) periods of downtime as we move our services whilst also changing them to be faster and more responsive. Any updates will be posted in freedesktop/freedesktop#2011 as it becomes clear, and any downtime will be announced with further broadcast messages.
Second time, I used 200 instances of xev (on top of ~96 that started with my session). No errors this time, but when I killall'd xev (all processes did end, and xrestop showed the client count drop), about 50 of their windows remained anyway. xkill is the only way I can seem to get rid of these dead windows.
Running 21.1.3
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Verified that with default MaxClients, I can do the same 200-300 xev/kcalc instances just fine - only error is hitting the client limit, no stability or correctness issues. Also verified xrestop's client count totals 256 exactly each time.
It is possible the maxclient may have grown some new bugs since it was first added, this is an option which is rarely exercised I reckon.
Also, this might run into some other limitation, for example, I tried to run Xnest -maxclient 2048 but ran into a much lower limit because the nofile limit was 1024 on my system (ulimit -n).
Also, all X11 clients are accounted for in that limit, that includes the window manager and all sort of (hidden) X11 clients. So for better testing, I used a bare xserver (Xnest in my case) w/out any window manager or desktop involved.
And for completeness, I tried with a window manager as well. At first, I tried with mutter but mutter would just stop mapping new windows after a certain number.
So next, I tried with xfwm4 which coped better, with or without the compositor enabled. Ran the same test, and also made sure that keyboard events where routed correctly, chnaged focus between xev clients etc.
So yeah, best would be to capture the backtrace of the crash you experienced, hopefully it can sched some light on what happens in your test. Failing that, maybe running the xserver in valgrind.
I will try to remember next time I have to reboot (which could be months).
Do you know if there a non-systemd equivalent of coredumpctl? That sounds potentially useful... (but not enough to be worth all the annoyances of systemd)
I was not able to reproduce the segfault, but every single attempt left dead windows open, and I noticed xlsclients would be wrong even before killing them (often showing 0 clients, or only a few).
Here's a FatalError bt:
#0 0x0000000128cd7890 in FatalError (f=0x128d7d560 "client not in use\n") at ../xorg-server-21.1.3/os/log.c:984 args = <optimized out> args2 = <optimized out> beenhere = 0#1 0x0000000128bc8880 in AddResource (id=<optimized out>, type=<optimized out>, value=0x15e868470) at ../xorg-server-21.1.3/dix/resource.c:816 client = 33 rrec = 0x128e4cf18 <clientTable+1056> res = <optimized out> head = <optimized out>#2 0x0000000128b7f9d0 in CreateColormap (mid=<optimized out>, pScreen=0x152e63c10, pVisual=<optimized out>, ppcmap=0x7fffe7e14158, alloc=<optimized out>, client=<optimized out>) at ../xorg-server-21.1.3/dix/colormap.c:373 class = <optimized out> size = <optimized out> sizebytes = <optimized out> pmap = 0x15e868470 pent = <optimized out> i = <optimized out> ppix = <optimized out> pptr = <optimized out>#3 0x0000000128b91aa0 in ProcCreateColormap (client=0x153afd1a0) at ../xorg-server-21.1.3/dix/dispatch.c:2454 pVisual = <optimized out> pmap = 0x0 mid = 606076933 pWin = 0x152ef08e0 pScreen = <optimized out> stuff = 0x1535888e8 i = <optimized out> result = <optimized out>#4 0x0000000128b956d0 in Dispatch () at ../xorg-server-21.1.3/dix/dispatch.c:551 result = <optimized out> client = 0x153afd1a0 start_tick = 5470#5 0x0000000128b9a694 in dix_main (argc=<optimized out>, argv=0x7fffe7e146e8, envp=<optimized out>) at ../xorg-server-21.1.3/dix/main.c:272 i = <optimized out> alwaysCheckForInput = {0, 1}#6 0x0000000128d6b57c in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../xorg-server-21.1.3/dix/stubmain.c:34No locals.
And another (not sure what the context of this one was):
#0 0x0000000103d10afc in FreeGC (value=0x12d7dd5d0, gid=<optimized out>) at ../xorg-server-21.1.3/dix/gc.c:773 pGC = 0x12d7dd5d0#1 0x0000000103d1235c in CreateGC (pDrawable=<optimized out>, mask=<optimized out>, pval=0x133632e50, pStatus=0x7ffff2f1b8bc, gcid=<optimized out>, client=0x132b3dac0) at ../xorg-server-21.1.3/dix/gc.c:567 pGC = 0x12d7dd5d0#2 0x0000000103cef138 in ProcCreateGC (client=0x132b3dac0) at ../xorg-server-21.1.3/dix/dispatch.c:1568 error = 10 rc = <optimized out> pGC = <optimized out> pDraw = 0x1286708e0 len = 1 stuff = 0x133632e40#3 0x0000000103cf56d0 in Dispatch () at ../xorg-server-21.1.3/dix/dispatch.c:551 result = <optimized out> client = 0x132b3dac0 start_tick = 42585#4 0x0000000103cfa694 in dix_main (argc=<optimized out>, argv=0x7ffff2f1be48, envp=<optimized out>) at ../xorg-server-21.1.3/dix/main.c:272 i = <optimized out> alwaysCheckForInput = {0, 1}#5 0x0000000103ecb57c in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../xorg-server-21.1.3/dix/stubmain.c:34No locals.
I have 516 MB and 806 MB core dump files for each of these (111 MB total as zstd).
Downstream in Gentoo, Hank Leininger's hit this (with Option "MaxClients" "512") and reported it there, and shared the following reproducer:
With x11-base/xorg-server-21*, X clients start getting BadIDChoice errors once there are ~256 connections:
$ for A in $(seq 1 300) ; do xterm & sleep 0.2 ; done[212] 17654$ X Error of failed request: BadIDChoice (invalid resource ID chosen for this connection) Major opcode of failed request: 55 (X_CreateGC) Resource id in failed request: 0x20000000 Serial number of failed request: 3 Current serial number in output stream: 7
Notably, he says x11-base/xorg-server-1.20.* is fine, and downgrading makes things work again. It happens for me too when I try his reproducer.
This is indeed commit c7311654. Basically what happens is that ResourceClientBits() gets called wit the default value of 256before the MaxClient options is read from the config file, so the cached value (lower) remains:
ResourceClientBits: LimitClients=256 cached=0ResourceClientBits: LimitClients=256 cached=8X.Org X Server 1.21.1.99[…]ResourceClientBits: LimitClients=512 cached=8
And to be complete, the problem does not happen when using the command line option-maxclients directly, which explains why I could not reproduce :)
with
ResourceClientBits: LimitClients=512 cached=0ResourceClientBits: LimitClients=512 cached=9X.Org X Server 1.21.1.99[…]ResourceClientBits: LimitClients=512 cached=9
@ofourdan So sorry for not replying sooner -- I didn't see the emails at all and just looked at the bug again to check for updates, and saw these! Confirmed your patch works!