[Xcb] deadlock with xlib/xcb

[Jamey Sharp]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for reminding me about this thread, Christoph. You're right, I've
ignored it much too long.

Turns out I can trivially get a similar-looking hang and backtrace with
`ico -threads 2`, by waiting about ten seconds. That should make
debugging and testing easier. I'd noticed quite a while ago that
multithreaded ico hangs, but it's a dodgy enough use of Xlib to begin
with that I wrote it off as "probably not my fault". Your report has
made me rethink that.

On 8/9/07, Christoph Pfister <christophpfister at gmail.com> wrote:
> However Thread 16 had dpy->lock->locking_level == 1 ...

I believe that means that xine's use of XLockDisplay played a role in
this case?

However, the ico case has locking_level == 0 when the hang occurs, so I
don't think this is relevant.

> I have no idea were the actual bug is, but I see something like three
> possible conditions which would avoid this:
> - xlib.lock has to be released before calling xcb_wait_for_reply
> - xlib.lock must not be released before calling xcb_wait_for_reply
> - xcb has to deal with that situation internally

I tested option 2 (don't release the xcb-xlib lock around
xcb_wait_for_reply) because I'm not sure why I was dropping that lock
there in the first place. (I think it may have been a performance
optimization for multi-threaded Xlib-using applications.) Unfortunately,
the ico hang still occurs.

I'm out of time for today, unfortunately, but I wanted to at least share
what I've discovered so far.

Jamey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHI7oCp1aplQ4I9mURAnGOAKCJlNVbY5jVBZYlcOSuAAZXBFvcoACfXe8c
Gdik8B//+WvplF89whI50z0=
=K7MW
-----END PGP SIGNATURE-----