Bug 5960 - Intermittent failure of XCBConnect
Summary: Intermittent failure of XCBConnect
Status: RESOLVED WONTFIX
Alias: None
Product: XCB
Classification: Unclassified
Component: Library (show other bugs)
Version: unspecified
Hardware: All All
: high normal
Assignee: Jamey Sharp
QA Contact: xcb mailing list dummy
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-20 10:40 UTC by Jamey Sharp
Modified: 2019-02-16 12:54 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jamey Sharp 2006-02-20 10:40:44 UTC
On 20 Jun 2005 Carl Worth wrote to the mailing list about XCBConnect failing
occasionally. IIRC, Keithp said that this is due to the X server being coded for
old OS limitations, and Xlib just auto-retries in this case.
Comment 1 Jamey Sharp 2009-10-09 09:22:27 UTC
XCB needs to handle connection errors better; see libxtrans/Xtranssock.c for how it's been handled in Xlib. Patches welcome. :-)

For TCP sockets there's this comment, with a similar but different set of issues for Unix sockets:

If the error was ECONNREFUSED, the server may be overloaded
and we should try again.

If the error was EWOULDBLOCK or EINPROGRESS then the socket
was non-blocking and we should poll using select

If the error was EINTR, the connect was interrupted and we
should try again.
Comment 2 Bart Massey 2009-10-09 13:58:00 UTC
I don't recall exactly what Keithp thought was happening.  That said, I'm really uncomfortable with putting this kind of policy in core XCB, which is supposed to be all about mechanism.  I guess what I'd recommend is putting a routine in aux which is a persistent-attempt-to-open built on top of XCB core.  Maybe.

Among other things, I think the security implications of auto-retry are a bit interesting.  I can't offhand see where this breaks security in obvious ways, but I can imagine attempts to spoof an X server being aided and abetted...
Comment 3 Uli Schlachter 2012-02-10 12:01:33 UTC
From a quick look, I can't see where (current, xcb-ified) Xlib would do retry. XOpenDisplay() calls _XConnectXCB() which just calls into xcb_connect() once. If that fails, Xlib retries with other protocols. No looping involved...?

Did Xlib do better pre-xcb?
Comment 4 Daniel Stone 2019-02-16 12:54:33 UTC
> That said, I'm really uncomfortable with putting this kind of policy in core XCB, which is supposed to be all about mechanism.  I guess what I'd recommend is putting a routine in aux which is a persistent-attempt-to-open built on top of XCB core.  Maybe.

Yeah, I agree.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.