[Xcb] Calling XAllocID() twice causes assertion `ret != inval_id' failed

[Jamey Sharp]

On Sun, Jul 11, 2010 at 2:17 AM, Matthieu Herrb <matthieu.herrb at laas.fr> wrote:
> I'm trying to help someone understanding why an application using
> the old XView (from OpenWindows) toolkit is crashing with the infamous)
>
> xcb_io.c:378: _XAllocID: Assertion `ret != inval_id' failed.

This is a known bug in XView. It's using XAllocID, which should never
have been public, in a way that has never been safe. See this mail for
details:

http://lists.freedesktop.org/archives/xorg/2007-November/030209.html

In that mail I said that calling _XAllocIDs instead, as apparently a
now-missing patch did, would be safe. I no longer believe that's true,
although it will happen to work about as often as XAllocID did in old
libX11, which has apparently been good enough.

As I recall, XView doesn't really want server-unique XIDs, but just
locally unique integers. There are easier ways to arrange that...

If XView has a maintainer today, perhaps you can push them to fix their bugs?

> Indeed the program below reproduces the problem. Looking at libX11
> source code, it's obvious why this happens. Since XView is inherently
> not thread-safe, there is no multi-threading involved and
> XInitThreads() is never called, so dpy->lock is NULL and so _XIDHandler()
> is never called by XLockDisplay(), thus the xcb->next_xid field
> stays 'invalid_id'.

The path that updates next_xid in single-threaded applications is
SyncHandle, which strictly speaking was necessary for XView to work in
old libX11 too.

> I think this is a bug, and could be also one cause of
> https://bugs.freedesktop.org/show_bug.cgi?id=27552

Google Code Search isn't finding me any uses of XAllocID that are
broken like XView outside of XView itself, and I've audited all the
X.org libraries for this problem without finding anything important.
So I believe 27552 is unrelated, but then none of the users reporting
that bug have provided enough information for troubleshooting.

I'm not convinced that this is a bug for libX11 to fix. I'm happy to
listen to arguments to the contrary though.

Jamey