[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