[Xcb] xcb_io.c:378: _XAllocID: Assertion `ret != inval_id' failed

Josh Triplett josh at joshtriplett.org
Thu Oct 8 00:36:43 PDT 2009

On Wed, Oct 07, 2009 at 07:39:35PM -0700, Jamey Sharp wrote:
> On Wed, Oct 7, 2009 at 7:02 PM,  <fdsteve at ihug.co.nz> wrote:
> > First post from an X newbie - so please go easy on me :)
> You're off to a great start then. :-)

Seconded.  A bug report, diagnosis, bug-finding assertion, and suggested
fix?  Newbie status revoked. :)

> >     shminfo->shmseg = XAllocID(dpy);
> >     LockDisplay(dpy);
> >...
> > Is this a bug in XShmAttach? Should LockDisplay() be moved before the
> > XAllocId() line...?
> > I made and tested a patch with LockDisplay moved before XAllocID and it
> > definitely fixed our problem.
> Good work! I agree, XShmAttach is busted here.
> I've pushed a fix to libXext git. Thanks for the report!

We should try to poke an appropriate person to make sure a libXext
release gets made soon with this fix.

> >  I added an assert in XAllocID to try and find the offending caller:
> >
> >     if( dpy->lock && dpy->lock->mutex )
> >         assert( pthread_mutex_lock(dpy->lock->mutex) == EDEADLK );
> I wish we could print a warning when this condition fails, but I don't
> think it'll work portably. I'd be tempted to make it an assert, even,
> except I learned my lesson from the last time we shipped an assertion in
> libX11 to catch buggy callers. :-/

In theory, pthread_mutex_trylock should work portably.  However, that
seems like an expensive operation to add to every XAllocID just for a
debugging assertion.  So no, I don't think we can check this both
portably and efficiently.

- Josh Triplett

More information about the Xcb mailing list