[Xcb] print backtraces in case an assert fails inside xlib/xcb

[Barton C Massey]

In message <200706071915.52612.christophpfister at gmail.com> you wrote:
[...]
> Am Donnerstag, 7. Juni 2007 19:02 schrieb a r:
> > BTW, what is the reason behind this assert? Will disabling it result
> > in crash of xserver or system?
> 
> No, but the assert is because of a clear bug somewhere which has to be fixed 
> and not just ignored.

Also, this application bug could result in a very messy
application hang or crash.  If this assert is encountered it
means that the application (or some library it calls) has
gotten very confused about its Xlib thread locking.  In
general, nothing good can come of this.

Applications and libraries that don't care about Xlib
threading shouldn't be calling Xlib's lock and unlock
functions.  Ones that do may encounter all kinds of errors
after they try to unlock a display that is already unlocked,
or lock one that is already locked.  On the positive side,
we believe that using XCB as an underlying transport removes
some potentially serious locking bugs in Xlib, so
applications that do use the API correctly may experience
more reliable operation.  (Although any threaded X
application should seriously consider moving to run directly
on XCB.  Its support for "transparent" threading is
remarkably easier to use.)

It is unfortunate that Xlib's thread support has been so
"forgiving" (in the sense of giving wrong answers instead of
just crashing) for so long.  It means that we had a big
backlog of debugging to do when we started doing it right.
I think the last *major* offender in this category is Sun
Java.  We have a fix for Sun Java 1.5 and 1.6; we're hoping
that Sun will incorporate it, or hurry up and get their
GPL'ed bits out the door so that we can do ourselves.

Hope this clarifies the situation.

    Bart Massey
    bart at cs.pdx.edu