[Xcb] [Bug 27552] Lots of processes crash in XCreatePixmap() with _XAllocID: Assertion `ret != inval_id' failed

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=27552

Jamey Sharp <jamey at minilop.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xcb at lists.freedesktop.org

--- Comment #1 from Jamey Sharp <jamey at minilop.net> 2010-04-09 17:35:03 PDT ---
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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.