Skip to content
Snippets Groups Projects
  1. Oct 05, 2012
  2. Sep 30, 2012
  3. Sep 25, 2012
  4. Sep 18, 2012
  5. Aug 30, 2012
  6. Aug 25, 2012
  7. Aug 14, 2012
  8. Apr 22, 2012
  9. Mar 27, 2012
  10. Mar 26, 2012
  11. Mar 09, 2012
  12. Mar 08, 2012
    • Uli Schlachter's avatar
      Fix a busy loop on BSD and Mac OS · 236f914e
      Uli Schlachter authored
      On FreeBSD MSG_WAITALL on a non-blocking socket fails immediately if less bytes
      than were asked for are available. This is different than the behavior on linux
      where as many bytes as are available are returned in this case. Other OS
      apparently follow the FreeBSD behavior.
      
      _xcb_in_read() is used to fill xcb's read buffer, thus this function will call
      recv() with a big length argument (xcb's read buffer is by default 16 KiB
      large). That many bytes are highly unlikely to be available in the kernel
      buffer.
      
      This means that _xcb_in_read() always failed on FreeBSD. Since the socket was
      still signaled as readable by poll(), this bug even resulted in a busy loop.
      
      The same issue is present in read_block(), but here it is slightly different.
      read_block() is called when we read the first few bytes of an event or a reply,
      so that we already know its length. This means that we should be able to use
      MSG_WAITALL here, because we know how many bytes there have to be.
      
      However, that function could busy loop, too, when only the first few bytes of
      the packet were sent while the rest is stuck somewhere on the way to us. Thus,
      MSG_WAITALL should be removed here, too.
      
      Thanks to Christoph Egger from Debian for noticing the problem, doing all the
      necessary debugging and figuring out what the problem was! This patch is 99%
      from debian. Thanks for all the work.
      
      This bug was introduced in commit 2dcf8b02.
      
      This commit also reverts commit 9061ee45.
      
      Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=45776
      
      
      
      Signed-off-by: default avatarUli Schlachter <psychon@znc.in>
      Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
      236f914e
    • Jeremy Huddleston Sequoia's avatar
      darwin: Use read(2) rather than recv(2) · 9061ee45
      Jeremy Huddleston Sequoia authored
      
      2dcf8b02 was causing some regressions on
      darwin, so go back to using read(2) there until I have time to investigate
      further.
      
      Signed-off-by: default avatarJeremy Huddleston <jeremyhu@apple.com>
      9061ee45
  13. Feb 19, 2012
  14. Feb 10, 2012
  15. Feb 09, 2012
  16. Jan 28, 2012
    • Jon Turney's avatar
      Fix build of xcb_auth.c with XDMCP on WIN32 · 87b7bf87
      Jon Turney authored and Jeremy Huddleston Sequoia's avatar Jeremy Huddleston Sequoia committed
      
      Fix a redefinition problem which shows up when building for _WIN32 and
      libXdmcp is installed, so HASXDMAUTH is enabled
      
      It seems this is a special place in xcb as it uses other X11 library headers here
      
      If HASXDMAUTH is defined, include the wrapped windows.h before any header which
      includes it unwrapped, to avoid conflicts with types defined in X headers
      
      We need to include config.h and check HASXDMAUTH to avoid an unconditional dependency
      on x11proto headers
      
      In file included from install/include/X11/Xdmcp.h:19:0,
                       from git/xcb/libxcb/src/xcb_auth.c:52:
      install/include/X11/Xmd.h:120:14: error: conflicting types for 'INT32'
      /usr/i686-pc-mingw32/sys-root/mingw/include/basetsd.h:54:13: note: previous declaration of 'INT32' was here
      install/include/X11/Xmd.h:143:15: error: conflicting types for 'BOOL'
      /usr/i686-pc-mingw32/sys-root/mingw/include/windef.h:234:17: note: previous declaration of 'BOOL' was here
      
      Signed-off-by: default avatarJon TURNEY <jon.turney@dronecode.org.uk>
      Reviewed-by: default avatarJeremy Huddleston <jeremyhu@apple.com>
      87b7bf87
    • Jeremy Huddleston's avatar
      Revert "Fix include order with Xdmcp on WIN32" · 6db1a268
      Jeremy Huddleston authored and Jeremy Huddleston Sequoia's avatar Jeremy Huddleston Sequoia committed
      
      This reverts commit 0e9246de.
      
      This change caused build failures because <X11/Xdmcp.h> was never
      included under any circumstance.  This is because the check for
      HASXDMAUTH was moved before the inclusion of config.h (via xcbint.h)
      which defined it.
      
      Found-by: Tinderbox
      Signed-off-by: default avatarJeremy Huddleston <jeremyhu@apple.com>
      Reviewed-by: default avatarJon TURNEY <jon.turney@dronecode.org.uk>
      6db1a268
  17. Jan 12, 2012
  18. Jan 11, 2012
  19. Sep 02, 2011
    • Uli Schlachter's avatar
      Fix a dead-lock due to xcb_poll_for_reply · 5ceeaaa4
      Uli Schlachter authored and Peter Harris's avatar Peter Harris committed
      Imagine two threads:
      
      Thread#1: for(;;) { xcb_get_input_focus_reply(c, xcb_get_input_focus(c), 0); }
      
      Thread#2: for(;;) { xcb_poll_for_event(c); }
      
      Since xcb_poll_for_event() calls _xcb_in_read() directly without synchronizing
      with any other readers, this causes two threads to end up calling recv() at the
      same time. We now have a race because any of these two threads could get read
      the GetInputFocus reply.
      
      If thread#2 reads this reply, it will be put in the appropriate queue and
      thread#1 will still be stuck in recv(), although its reply was already received.
      If no other reply or event causes this thread to wake up, the process deadlocks.
      
      To fix this, we have to make sure that there is only ever one thread reading
      from the connection. The obvious solution is to check in poll_for_next_event()
      if another thread is already reading (in which case c->in.reading != 0) and not
      to read from the wire in this case.
      
      This solution is actually correct if we assume that the other thread is blocked
      in poll() which means there isn't any data which can be read. Since we already
      checked that there is no event in the queue this means that
      poll_for_next_event() didn't find any event to return.
      
      There might be a small race here where the other thread already determined that
      there is data to read, but it still has to wait for c->iolock. However, this
      means that the next poll_for_next_event() will be able to read the event, so
      this shouldn't cause any problems.
      
      Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=40372
      
      
      
      Signed-off-by: default avatarUli Schlachter <psychon@znc.in>
      Signed-off-by: default avatarPeter Harris <pharris@opentext.com>
      5ceeaaa4
  20. Aug 24, 2011
  21. Aug 18, 2011
    • Michael Stapelberg's avatar
      Drop AI_ADDRCONFIG when resolving TCP addresses · 4f25ee16
      Michael Stapelberg authored and Jamey Sharp's avatar Jamey Sharp committed
      When a system is completely offline (no interface has an IP address but 'lo'),
      xcb could not connect to localhost via TCP, e.g. connections with
      DISPLAY=127.0.0.1:0 fail.
      
      AI_ADDRCONFIG will only return IPv4 addresses if the system has an IPv4
      address configured (likewise for IPv6). This also takes place when
      resolving localhost (or 127.0.0.0/8 or ::1). Also, as per RFC 3493,
      loopback addresses are not considered as valid addresses when
      determining whether to return IPv4 or IPv6 addresses.
      
      As per mailing-list discussion on the xcb list started with message
      20110813215405.5818a0c1@x200, the AI_ADDRCONFIG flag is there for historical
      reasons:
      
          In the old days, the "default on-link" assumption in IPv6 made the flag vey
          much indispensable for dual-stack hosts on IPv4-only networks. Without it,
          there would be long timeouts trying non-existent IPv6 connectivity. Nowadays,
          this assumption has been flagged as historic bad practice by IETF, and hosts
          should have been updated to not make it anymore.
      
          Then AI_ADDRCONFIG became mostly cosmetic: it avoids phony "Protocol family
          not supported" or "Host unreachable" errors while trying to connect to a dual-
          stack mode from a host with no support for source address selection.
      
          Nowadays, on up-to-date systems, this flag is completely useless. Then again,
          I understood only the very latest MacOS release is "up-to-date" with this
          definition.
      4f25ee16
  22. May 12, 2011
  23. May 04, 2011
    • David Coles's avatar
      Add support for building with Python 3 · 294c9f45
      David Coles authored and Julien Danjou's avatar Julien Danjou committed
      Python 3 introduces some language changes that cause issues when running
      c_client.py. This also breaks compatibility with Python 2.5 since it does not
      support the "as" statement in try/except blocks and does not have reduce() in
      the functools package.
      
      The main changes are:
      * try/except blocks require `except ... as ...:` to resolve syntactical ambiguity
      * map() and filter() return iterators rather than lists in Python 3
      * reduce() is now in functools package (and not built-in in Python 3)
      * Dictionaries don't have a has_key() method in Python 3
      * None and int types can't be directly compared in Python 3
      * print() is a statement in Python 3
      
      See http://diveintopython3.org/porting-code-to-python-3-with-2to3.html
      
       and
      PEP-3110 for details.
      
      Verified on Python 2.6.5 and 3.1.3.
      
      Signed-off-by: default avatarDavid Coles <dcoles@gaikai.com>
      Signed-off-by: default avatarJulien Danjou <julien@danjou.info>
      294c9f45
  24. Apr 12, 2011
Loading