1. 15 Nov, 2020 1 commit
    • Keith Packard's avatar
      Avoid recursing through _XError due to sequence adjustment · 30ccef3a
      Keith Packard authored
      This patch is based on research done by Dmitry Osipenko to uncover the
      cause of a large class of Xlib lockups.
      _XError must unlock and re-lock the display around the call to the
      user error handler function. When re-locking the display, two
      functions are called to ensure that the display is ready to generate a request:
      The first ensures that there is at least one XID available to use
      (possibly calling _xcb_generate_id to do so). The second makes sure a
      reply is received at least every 65535 requests to keep sequence
      numbers in sync (possibly generating a GetInputFocus request and
      synchronously awaiting the reply).
      If the second of these does generate a GetInputFocus request and wait
      for the reply, then a pending error will cause recursion into _XError,
      which deadlocks the display.
      One seemingly easy fix is to have _XError avoid those calls by
      invoking InternalLockDisplay instead of LockDisplay. That function
      does everything that LockDisplay does *except* call those final two
      functions which may end up receiving an error.
      However, that doesn't protect the system from applications which call
      some legal Xlib function from within their error handler. Any Xlib
      function which cannot generate protocol or wait for events is valid,
      including many which invoke LockDisplay.
      What we need to do is make LockDisplay skip these two function calls
      precisely when it is called from within the _XError context for the
      same display.
      This patch accomplishes this by creating a list of threads in the
      display which are in _XError, and then having LockDisplay check the
      current thread against those list elements.
      Inspired-by: Dmitry Osipenko's avatarDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Tested-by: Dmitry Osipenko's avatarDmitry Osipenko <digetx@gmail.com>
      Reviewed-by: Dmitry Osipenko's avatarDmitry Osipenko <digetx@gmail.com>
  2. 13 Nov, 2020 3 commits
  3. 09 Nov, 2020 4 commits
  4. 08 Nov, 2020 2 commits
  5. 05 Nov, 2020 2 commits
  6. 01 Nov, 2020 4 commits
  7. 15 Oct, 2020 2 commits
  8. 10 Oct, 2020 2 commits
    • Ross Burton's avatar
      cpprules.in: squash whitespace in generated files · a37986f7
      Ross Burton authored and Alan Coopersmith's avatar Alan Coopersmith committed
      CPP is used to generate files, but as cpp reads files from the build host the
      output has a number of blank lines at the beginning which varies depending on
      what GCC and friends is used.
      Pathalogical example:
       $ cpp -undef -traditional /dev/null
       # 1 "/dev/null"
       # 1 "<built-in>"
       # 1 "<command-line>"
       # 31 "<command-line>"
       # 1 "/usr/include/stdc-predef.h" 1 3 4
       # 17 "/usr/include/stdc-predef.h" 3 4
       [ 40 blank line ]
       # 32 "<command-line>" 2
       # 1 "/dev/null"
      So depending on the content of stdc-predef.h and what other headers CPP will
      load, the amount of whitespace in the generates files varies. This can result in
      differences in reproducible environments, and file conflicts in multilib
      As whitespace is irrelevant to these machine-readable files, extend the sed to
      just delete blank lines.
    • Carmina16's avatar
      Adding ia and ie locales · 16192ce2
      Carmina16 authored and Alan Coopersmith's avatar Alan Coopersmith committed
  9. 28 Sep, 2020 1 commit
  10. 21 Sep, 2020 1 commit
    • Krzesimir Nowak's avatar
      Fix leaking modifiers string. · 1a9269a9
      Krzesimir Nowak authored and Adam Jackson's avatar Adam Jackson committed
      Reported by valgrind:
      ==118175== 17 bytes in 1 blocks are definitely lost in loss record 13 of 1,675
      ==118175==    at 0x483A809: malloc (vg_replace_malloc.c:307)
      ==118175==    by 0x5CD1B46: _XlcDefaultMapModifiers (in /usr/lib64/libX11.so.6.3.0)
      ==118175==    by 0x5CD1F1A: XSetLocaleModifiers (in /usr/lib64/libX11.so.6.3.0)
      ==118175==    by 0x496841C: X11_InitKeyboard (SDL_x11keyboard.c:324)
      ==118175==    by 0x496F0CA: X11_VideoInit (SDL_x11video.c:455)
      ==118175==    by 0x494747B: SDL_VideoInit_REAL (SDL_video.c:532)
      ==118175==    by 0x489E886: SDL_InitSubSystem_REAL (SDL.c:206)
      ==118175==    by 0x402634: main (fade.cc:35)
  11. 28 Aug, 2020 6 commits
  12. 24 Aug, 2020 1 commit
  13. 19 Aug, 2020 1 commit
  14. 17 Aug, 2020 1 commit
  15. 14 Aug, 2020 1 commit
  16. 10 Aug, 2020 1 commit
  17. 06 Aug, 2020 2 commits
  18. 02 Aug, 2020 1 commit
    • Yichao Yu's avatar
      Fix size calculation in `_XimAttributeToValue`. · 93fce3f4
      Yichao Yu authored
      The check here guards the read below.
      For `XimType_XIMStyles`, these are `num` of `CARD32` and for `XimType_XIMHotKeyTriggers`
      these are `num` of `XIMTRIGGERKEY` ref[1] which is defined as 3 x `CARD32`.
      (There are data after the `XIMTRIGGERKEY` according to the spec but they are not read by this
      function and doesn't need to be checked.)
      The old code here used the native datatype size instead of the wire protocol size causing
      the check to always fail.
      Also fix the size calculation for the header (size). It is 2 x CARD16 for both types
      despite the unused `CARD16` for `XimType_XIMStyles`.
      [1] https://www.x.org/releases/X11R7.6/doc/libX11/specs/XIM/xim.html#Input_Method_Styles
      This fixes a regression caused by 388b303c in 1.6.10.
      Fix #116
  19. 30 Jul, 2020 1 commit
  20. 24 Jul, 2020 3 commits