[Xcb] [Bug 59361] Deadlock in _XReply when recursing through _XSeqSyncFunction

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=59361

--- Comment #4 from Peter Horrocks <p.horrocks89 at gmail.com> ---
It looks like commit 83e1ba59c48c79f8b0a7e7aa0b9c9cfd84fa403d introduced the
problem.

The commit unlocks the display when an application-defined error handler is
invoked, but re-locking the display requires re-syncing the sequence numbers
which requires a remote call.

The commit author couldn't remember why the display lock was held while the
error function was called - I guess the sequence number re-sync was the reason.

Reverting the commit fixes the problem.

In the meantime, an application can use this code to work around the problem -
it uses a custom extension error handler to cause XError to return before it
unlocks/locks the screen:

typedef Bool (*WireToErrorType)(Display*, XErrorEvent*, xError*);

const int NUM_HANDLERS = 256;
WireToErrorType __oldHandlers[NUM_HANDLERS] = {0};

Bool __xErrorHandler(
        Display*     display,
        XErrorEvent* event,
        xError*      error
        )
{
    // Call any previous handler first in case it needs to do real work.
    auto code = static_cast<int>(event->error_code);
    if(__oldHandlers[code] != NULL)
    {
        __oldHandlers[code](display, event, error);
    }

    // Always return false so the error does not get passed to the normal
    // application defined handler.
    return False;
}

void applyXDeadlockFix(Display* display)
{
    for(auto i = 0; i < NUM_HANDLERS; ++i)
    {
        XESetWireToError(display, i, &__xErrorHandler);
    }
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20141126/c205eea9/attachment.html>