Comment 17 for bug 507062

It would be really nice to know where the last call to XIDAlloc was before the one that fails, and for that I'd love to have a minimal test case.

Any chance these applications are using libX11 from more than one thread? I notice in some stack traces, like <http://launchpadlibrarian.net/31837770/ThreadStacktrace.txt> that a second thread is waiting in libpulse; and in <http://launchpadlibrarian.net/31032259/ThreadStacktrace.txt>, g_main_loop_run is in a different thread than the cairo call that precedes the assert.

I could believe there's a race in how Xlib asks XCB for XIDs, but I'd like to know if that would be a plausible explanation for the reports you're actually seeing. It looks like a fair number of the reported stack traces are single-threaded, making that an unlikely explanation for those reports. :-) It's possible there are two separate bugs here, I suppose...

In lieu of a minimal test, perhaps you can tell me which X extensions these applications have in common? Perhaps the client library for some extension allocates an XID but is missing a SyncHandle call; if the next X request also tries to allocate an XID you'd get this assertion failure.

I've just reviewed everything in xorg/lib, just in case, for bad use of SyncHandle, XAllocID, or XAllocIDs. I found quite a few things to quibble with, but nothing that seems likely to have caused these reports. I've pushed fixes in these modules, so you can check whether anything there seems plausible.

libXcomposite/
libXdamage/
libXext/
libXfixes/
libXi/
libXrender/
libXTrap/

In short, I don't have a good hypothesis yet.

> http://launchpadlibrarian.net/23717282/Stacktrace.txt

I'm ignoring this one: the application was exiting, and a destructor tried to access the Display to free a resource. I'd guess the display was already gone at that point. I've seen that kind of pattern in quite a few Qt stack traces.