1. 19 May, 2019 1 commit
    • Martin Dørum's avatar
      Handle EINTR from recvmsg in _xcb_in_read · 21324989
      Martin Dørum authored
      I have a GTK application which occasionally crashes with an "interrupted
      system call" g_message from gdk. After a lot of debugging, I've found
      that the call to recvmsg in _xcb_in_read occasionally fails with EINTR,
      and instead of retrying the system call, xcb would just shut down the
      This change makes _xcb_in_read treat EINTR the same as it would treat
      EAGAIN; it returns 1 and libX11 ends up calling xcb_poll_for_event
      again (from what I have understood).
      I have spoken with a few people who think recvmsg failing with EINTR in
      this case shouldn't ever happen, and I don't know enough to agree or
      disagree with that. In case anyone wants to dig further and try to
      figure out why the recvmsg call sometimes fails with EINTR, here's the
      backtrace from inside of _xcb_in_read where that happened:
      Thread 1 "beanbar" hit Breakpoint 1, _xcb_in_read (c=c@entry=0x55ecbe4aba80) at xcb_in.c:1059
      1059                fprintf(stderr, "Hello World am %s:%i, errno is %s\n", __FILE__, __LINE__, strerror(errno));
      (gdb) bt
      0  0x00007fa48fa48639 in _xcb_in_read (c=c@entry=0x55ecbe4aba80) at xcb_in.c:1059
      1  0x00007fa48fa489d8 in poll_for_next_event (c=0x55ecbe4aba80, queued=queued@entry=0) at xcb_in.c:352
      2  0x00007fa48fa48a3d in poll_for_next_event (queued=0, c=<optimized out>) at xcb_in.c:722
      3  0x00007fa48fa48a3d in xcb_poll_for_event (c=<optimized out>) at xcb_in.c:722
      4  0x00007fa4908d1b7e in poll_for_event (dpy=dpy@entry=0x55ecbe4a9730, queued_only=queued_only@entry=0) at xcb_io.c:245
      5  0x00007fa4908d1cf0 in poll_for_response (dpy=dpy@entry=0x55ecbe4a9730) at xcb_io.c:303
      6  0x00007fa4908d1fed in _XEventsQueued (mode=2, dpy=0x55ecbe4a9730) at xcb_io.c:363
      7  0x00007fa4908d1fed in _XEventsQueued (dpy=dpy@entry=0x55ecbe4a9730, mode=mode@entry=2) at xcb_io.c:344
      8  0x00007fa4908c3d47 in XPending (dpy=0x55ecbe4a9730) at Pending.c:55
      9  0x00007fa493cadbc7 in  () at /usr/lib/libgdk-3.so.0
      10 0x00007fa49234d08a in g_main_context_prepare () at /usr/lib/libglib-2.0.so.0
      11 0x00007fa49234d6e6 in  () at /usr/lib/libglib-2.0.so.0
      12 0x00007fa49234d8ae in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
      13 0x00007fa4938b920e in g_application_run () at /usr/lib/libgio-2.0.so.0
      14 0x000055ecbc820af4 in main (argc=1, argv=0x7ffd06238098) at src/main.c:190
      Signed-off-by: Martin Dørum's avatarMartin Dørum <martid0311@gmail.com>
  2. 25 Apr, 2019 1 commit
  3. 17 Feb, 2019 2 commits
  4. 16 Feb, 2019 2 commits
  5. 07 Jan, 2019 1 commit
  6. 27 Sep, 2018 1 commit
  7. 21 Aug, 2018 1 commit
    • Erik Kurzinger's avatar
      don't flag extra reply in xcb_take_socket · bbda345a
      Erik Kurzinger authored
      If any flags are specified in a call to xcb_take_socket,
      they should only be applied to replies for requests sent
      after that function returns (and until the socket is
      re-acquired by XCB).
      Previously, they would also be incorrectly applied to the
      reply for the last request sent before the socket was taken.
      For instance, in this example program the reply for the
      GetInputFocus request gets discarded, even though it was
      sent before the socket was taken. This results in the
      call to retrieve the reply hanging indefinitely.
      static void return_socket(void *closure) {}
      int main(void)
          Display *dpy = XOpenDisplay(NULL);
          xcb_connection_t *c = XGetXCBConnection(dpy);
          xcb_get_input_focus_cookie_t cookie = xcb_get_input_focus_unchecked(c);
          uint64_t seq;
          xcb_take_socket(c, return_socket, dpy, XCB_REQUEST_DISCARD_REPLY, &seq);
          xcb_generic_error_t *err;
          xcb_get_input_focus_reply(c, cookie, &err);
      In practice, this has been causing intermittent KWin crashes when
      used in combination with the proprietary NVIDIA driver such as
      https://bugs.kde.org/show_bug.cgi?id=386370 since when Xlib fails to
      retrieve one of these incorrectly discarded replies it triggers
      an IO error.
      Signed-off-by: Erik Kurzinger's avatarErik Kurzinger <ekurzinger@nvidia.com>
      Signed-off-by: Uli Schlachter's avatarUli Schlachter <psychon@znc.in>
  8. 28 Feb, 2018 1 commit
  9. 05 Jun, 2017 2 commits
  10. 13 May, 2017 2 commits
  11. 01 Apr, 2017 1 commit
  12. 11 Mar, 2017 3 commits
    • Christian Linhart's avatar
      add support for eventstruct · ee9dfc9a
      Christian Linhart authored
      eventstruct allows to use events as part of requests.
      This is, e.g., needed by xcb_input_send_extension_event.
      Signed-off-by: Christian Linhart's avatarChristian Linhart <chris@demorecorder.com>
    • Christian Linhart's avatar
      optionally build the GE extension · 0c2c5d50
      Christian Linhart authored
      xcb contains an xml-definition for the GenericEvent extension
      but this extension was neither generated nor built.
      This patch enables optional building of the GenericEvent extension
      with configure option --enable-ge
      By default, the GenericEvent extension is not built.
      Normally this is not needed by application programs
      because there is implicit support for the GE-extension
      for the specific events built with this extension.
      But it may be useful for X-protocol analyzers and stuff like that.
      Signed-off-by: Christian Linhart's avatarChristian Linhart <chris@demorecorder.com>
    • Christian Linhart's avatar
      move symbol lookup of sumof expr to the parser · 9bce1f72
      Christian Linhart authored
      replace the complicated symboltable lookup for sumof expr
      by accessing the lenfield of the expr-object.
      This requires the corresponding patch for xcb/proto
      which sets the lenfield accordingly.
      This should be OK because for official releases we define
      that dependency in the build system.
      For getting versions off the HEAD of the git repo, it should
      be obvious that xcb/proto and xcb/libxcb have to be updated together.
      I have tested this patch and it generates exactly the same code
      as before.
      Tested-by: Christian Linhart's avatarChristian Linhart <chris@demorecorder.com>
      Signed-off-by: Christian Linhart's avatarChristian Linhart <chris@demorecorder.com>
  13. 29 May, 2016 2 commits
    • Alan Coopersmith's avatar
      Correct @param "e" to "error" in xcb_poll_for_reply*() · 65b298c7
      Alan Coopersmith authored
      Found by clang -Wdocumentation:
      ./xcbext.h:271:11: warning: parameter 'e' not found in the function
            declaration [-Wdocumentation]
       * @param e Location to store errors in, or NULL. Ignored for un...
      ./xcbext.h:271:11: note: did you mean 'error'?
       * @param e Location to store errors in, or NULL. Ignored for un...
      ./xcbext.h:283:11: warning: parameter 'e' not found in the function
            declaration [-Wdocumentation]
       * @param e Location to store errors in, or NULL. Ignored for un...
      ./xcbext.h:283:11: note: did you mean 'error'?
       * @param e Location to store errors in, or NULL. Ignored for un...
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Signed-off-by: Uli Schlachter's avatarUli Schlachter <psychon@znc.in>
    • Alan Coopersmith's avatar
      Remove : from @param names in manually written headers · 32a90845
      Alan Coopersmith authored
      Makes style match the @param names in autogenerated headers and makes
      clang -Wdocumentation stop complaining about all of them:
      ./xcb.h:523:11: warning: parameter 'display:' not found in the function
            declaration [-Wdocumentation]
       * @param display: A pointer to the display number.
      ./xcb.h:523:11: note: did you mean 'display'?
       * @param display: A pointer to the display number.
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Signed-off-by: Uli Schlachter's avatarUli Schlachter <psychon@znc.in>
  14. 28 May, 2016 1 commit
  15. 18 May, 2016 1 commit
  16. 14 May, 2016 1 commit
  17. 01 Feb, 2016 2 commits
  18. 06 Jan, 2016 3 commits
  19. 21 Sep, 2015 1 commit
  20. 13 Aug, 2015 1 commit
  21. 04 Jul, 2015 2 commits
  22. 25 Jun, 2015 1 commit
    • Uli Schlachter's avatar
      Fix a thread hang with xcb_wait_for_special_event() · 5b40681c
      Uli Schlachter authored
      Consider the following:
      - Two threads are calling xcb_wait_for_special_event() and xcb_wait_for_reply()
      - The thread doing xcb_wait_for_reply() wins the race and poll()s the socket for
      - The other thread will be put to sleep on the special_event_cond of the special
        event (this is done in _xcb_conn_wait() via the argument
        xcb_wait_for_special_event() gives it).
      - The first thread gets its reply, but does not yet receive any special event.
      In this case, the first thread will return to its caller. On its way out, it
      will call _xcb_in_wake_up_next_reader(), but that function cannot wake up
      anything since so far it did not handle xcb_wait_for_special_event().
      Thus, the first thread stays blocked on the condition variable and no thread
      tries to read from the socket.
      A test case demonstrating this problem is available at the bug report.
      Fix this similar to how we handle this with xcb_wait_for_reply():
      The function wait_for_reply() adds an entry into a linked list of threads that
      wait for a reply. Via this list, _xcb_in_wake_up_next_reader() can wake up this
      thread so that it can call _xcb_conn_wait() again and then poll()s the socket.
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84252Signed-off-by: Uli Schlachter's avatarUli Schlachter <psychon@znc.in>
      Tested-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
  23. 12 Jun, 2015 6 commits
    • Michel Dänzer's avatar
      Call _xcb_wake_up_next_reader from xcb_wait_for_special_event · f85661c3
      Michel Dänzer authored
      All functions calling _xcb_conn_wait() must make sure that waiting
      readers are woken up when we read a reply or event that they are waiting
      for. xcb_wait_for_special_event() did not do so. This adds the missing
      call to_xcb_in_wake_up_next_reader().
      Fixes deadlock when waiting for a special event and concurrently
      processing the display connection queue in another thread.
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84252Tested-by: 's avatarThomas Daede <bztdlinux@gmail.com>
      Tested-by: 's avatarClément Guérin <geecko.dev@free.fr>
      Reviewed-by: Uli Schlachter's avatarUli Schlachter <psychon@znc.in>
      Signed-off-by: Michel Dänzer's avatarMichel Dänzer <michel@daenzer.net>
      Signed-off-by: Uli Schlachter's avatarUli Schlachter <psychon@znc.in>
    • Uli Schlachter's avatar
      send_fds(): Handle too many outstanding FDs to send · 8584c0e0
      Uli Schlachter authored
      Before this patch, the following code caused an endless loop in send_fds(),
      because the queue of FDs to send was eventually full, but _xcb_out_flush_to()
      didn't make any progress, since there was no request to send:
         while (1) { xcb_send_fd(conn, dup(some_fd)); }
      Fix this by sending a sync when flushing didn't make any progress. That way we
      actually have something to send and can attach the pending FDs.
      Because send_fds() can now send requests, the code in
      xcb_send_request_with_fds64() has to be changed. It has to call send_fds()
      before it establishes a good sequence number for the request it wants to send.
      Signed-off-by: Uli Schlachter's avatarUli Schlachter <psychon@znc.in>
    • Uli Schlachter's avatar
    • Uli Schlachter's avatar
      Add xcb_send_request_with_fds() and *_with_fds64() · b15aa6bd
      Uli Schlachter authored
      Doing xcb_send_fd(), xcb_send_request() is racy. If two threads do this at the
      same time, they could mix up their file descriptors. This commit makes it
      possibly to fix this race by providing a single function which does everything
      that is needed.
      Signed-off-by: Uli Schlachter's avatarUli Schlachter <psychon@znc.in>
    • Uli Schlachter's avatar
      send_fds(): Make sure no other thread interrupts us · cc04cfb4
      Uli Schlachter authored
      Two threads trying to send fds at the same time could interfere. To guarantee a
      correct ordering, we have to use correct locking. The code in send_fds() missed
      one case: If there was another thread already writing requests, we slept on the
      "done with writing" condition variable (c->out.cond). This would allow other
      threads to re-acquire the iolock before us and could cause fds to be sent out of
      To fix this, at the beginning of send_fds() we now make sure that no other
      thread is already writing requests. This is what prepare_socket_request() does.
      Additionally, it gets the socket back in case xcb_take_socket() was called,
      which is a good thing, too, since fds are only sent with corresponding requests.
    • Uli Schlachter's avatar
      xcb_send_fd(): Always close fds · 25f9e7e4
      Uli Schlachter authored
      The API docs for xcb_send_fd() says "After this function returns, the file
      descriptor given is owned by xcb and will be closed eventually".
      Let the implementation live up to its documentation. We now also close fds if fd
      passing is unavailable (!HAVE_SENDMSG) and when the connection is in an error
      (This also does sneak in some preparatory functions for follow-up commits and
      thus does things in a more complicated way than really necessary.)
      Signed-off-by: Uli Schlachter's avatarUli Schlachter <psychon@znc.in>
  24. 30 May, 2015 1 commit