xcb_generate_id() returns -1 (well, ~0) under some error conditions. However, _XIDHandler() in Xlib doesn't check for it, and if this value is returned, it's saved in dpy->xcb->next_xid and causes an assertion failure in _XAllocID() at a later point. This is my guess as to what happened here: https://bugs.kde.org/show_bug.cgi?id=192468 -- I mean, it's the only concievable codepath leading to that assertion being triggered. The return value from xcb_generate_id() should be checked, and errors should be handled gracefully.
Created attachment 29195 [details] [review] 0001-_XAllocID-don-t-assert-when-running-out-of-IDs-23690.patch Just removing the assert seems to trigger the BadIDChoice error in the server. The client can then handle these gracefully. Patch sent to Jamey for review, there may be some hidden details.
Looking through libX11's git log, I don't see this. What's the status of it?
BadIDChoice isn't something the client is expected to handle gracefully. Or even capable of handling gracefully, for that matter; XID choice is xlib's job. The paths through which xcb_generate_id can return -1 are, afaict, exactly those paths that are fatal: either the socket is already in an error condition, or the server doesn't support XC-MISC, or the server thinks the client is literally out of XIDs. It might be interesting to see which of these it is.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/lib/libx11/issues/7.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.