Discussion:
[Bug 59361] Deadlock in _XReply when recursing through _XSeqSyncFunction
bugzilla-daemon-CC+
2013-01-14 16:29:23 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=59361

Alan Coopersmith <alan.coopersmith-QHcLZuEGTsvQT0dZR+***@public.gmane.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |xcb-***@public.gmane.org
--
You are receiving this mail because:
You are on the CC list for the bug.
bugzilla-daemon-CC+
2013-02-17 16:19:00 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=59361

--- Comment #2 from Daniel Martin <consume.noise-***@public.gmane.org> ---
Created attachment 74990
--> https://bugs.freedesktop.org/attachment.cgi?id=74990&action=edit
Bugfix?

At least this patch makes the test case working here. But, I haven't tested it
further and don't know howto. (Except from installing Qt5 stuff.)
--
You are receiving this mail because:
You are on the CC list for the bug.
bugzilla-daemon-CC+
2013-02-17 17:10:39 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=59361

--- Comment #3 from Uli Schlachter <psychon-***@public.gmane.org> ---
Do(In reply to comment #2)
Created attachment 74990 [details] [review]
Bugfix?
At least this patch makes the test case working here. But, I haven't tested
it further and don't know howto. (Except from installing Qt5 stuff.)
Doesn't this patch make Xlib lose track of sequence numbers? After all, this
GetInputFocus request is meant as a synchronization point to make sure that
something close to the current sequence number is known. (However, I don't know
much about Xlib internals)
--
You are receiving this mail because:
You are on the CC list for the bug.
b***@freedesktop.org
2014-11-26 22:22:00 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=59361

--- Comment #4 from Peter Horrocks <***@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.
b***@freedesktop.org
2018-08-10 20:10:24 UTC
Permalink
https://bugs.freedesktop.org/show_bug.cgi?id=59361

GitLab Migration User <gitlab-***@fdo.invalid> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |MOVED

--- Comment #5 from GitLab Migration User <gitlab-***@fdo.invalid> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/xorg/lib/libx11/issues/25.
--
You are receiving this mail because:
You are on the CC list for the bug.
Loading...