From 829da0516bd81bd548abec2927e8f538cf5b5629 Mon Sep 17 00:00:00 2001 From: Uli Schlachter Date: Sun, 13 Mar 2011 14:53:31 +0100 Subject: [PATCH] Fix deadlock in _XReply _XReply waited for user locks from other thread. However, if the other thread is in _XReply, too, it might be waiting for this thread to handle the current reply. Since this code already had the internal dock prior to the UnlockDisplay() two lines prior to the InternalLockDisplay() in question, it doesn't make sense to wait for user locks anyway. Ignoring those makes the deadlock go away. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=20708 Signed-off-by: Uli Schlachter --- src/xcb_io.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/src/xcb_io.c b/src/xcb_io.c index 7e685de..75f16ef 100644 --- a/src/xcb_io.c +++ b/src/xcb_io.c @@ -531,7 +531,12 @@ Status _XReply(Display *dpy, xReply *rep, int extra, Bool discard) req->reply_waiter = 1; UnlockDisplay(dpy); response = xcb_wait_for_reply(c, req->sequence, &error); - InternalLockDisplay(dpy, /* don't skip user locks */ 0); + /* This skips user locks, because we already had the lock before + * the UnlockDisplay() above, so we don't care if some other + * threads has a user lock. (The thread with the user lock + * might be in the ConditionWait() above waiting for us to handle + * this reply!) */ + InternalLockDisplay(dpy, /* do skip user locks */ 1); /* We have the response we're looking for. Now, before * letting anyone else process this sequence number, we -- 1.7.2.3