Skip to content
GitLab
Switch branch/tag
  1. 17 Nov, 2020 1 commit
  3. 16 Nov, 2020 2 commits
    • Peter Hutterer's avatar
      gitlab CI: add a basic build test · 960e2e0c
      Peter Hutterer authored 
      

Using Arch as base distribution here because we can expect our dependencies to
be up-to-date. We rely on the Arch for our dependencies rather than building
those from git (notably: xorg-macros, xtrans and libxcb).
Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      960e2e0c
    • Frediano Ziglio's avatar
      Fix poll_for_response race condition · dbb55e1a
      Frediano Ziglio authored and Peter Hutterer's avatar Peter Hutterer committed 
      In poll_for_response is it possible that event replies are skipped
and a more up to date message reply is returned.
This will cause next poll_for_event call to fail aborting the program.

This was proved using some slow ssh tunnel or using some program
to slow down server replies (I used a combination of xtrace and strace).

How the race happens:
- program enters into poll_for_response;
- poll_for_event is called but the server didn't still send the reply;
- pending_requests is not NULL because we send a request (see call
  to  append_pending_request in _XSend);
- xcb_poll_for_reply64 is called from poll_for_response;
- xcb_poll_for_reply64 will read from server, at this point
  server reply with an event (say sequence N) and the reply to our
  last request (say sequence N+1);
- xcb_poll_for_reply64 returns the reply for the request we asked;
- last_request_read is set to N+1 sequence in poll_for_response;
- poll_for_response returns the response to the request;
- poll_for_event is called (for instance from another poll_for_response);
- event with sequence N is retrieved;
- the N sequence is widen, however, as the "new" number computed from
  last_request_read is less than N the number is widened to N + 2^32
  (assuming last_request_read is still contained in 32 bit);
- poll_for_event enters the nested if statement as req is NULL;
- we compare the widen N (which now does not fit into 32 bit) with
  request (which fits into 32 bit) hitting the throw_thread_fail_assert.

To avoid the race condition and to avoid the sequence to go back
I check again for new events after getting the response and
return this last event if present saving the reply to return it
later.

To test the race and the fix it's helpful to add a delay (I used a
"usleep(5000)") before calling xcb_poll_for_reply64.

Original patch written by Frediano Ziglio, see
!34

Reworked primarily for readability by Peter Hutterer, see
!53

Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      dbb55e1a
  5. 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:

    _XIDHandler(dpy);
    _XSeqSyncFunction(dpy);

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>
      30ccef3a
  7. 13 Nov, 2020 3 commits
  9. 09 Nov, 2020 4 commits
  11. 08 Nov, 2020 2 commits
  13. 05 Nov, 2020 2 commits
  15. 01 Nov, 2020 4 commits
  17. 15 Oct, 2020 2 commits
  19. 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
environments.

As whitespace is irrelevant to these machine-readable files, extend the sed to
just delete blank lines.
      a37986f7
    • Carmina16's avatar
      Adding ia and ie locales · 16192ce2
      Carmina16 authored and Alan Coopersmith's avatar Alan Coopersmith committed
      16192ce2
  21. 28 Sep, 2020 1 commit
  23. 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)
```
      1a9269a9
  25. 28 Aug, 2020 6 commits
  27. 24 Aug, 2020 1 commit
  29. 19 Aug, 2020 1 commit
  31. 17 Aug, 2020 1 commit
  33. 14 Aug, 2020 1 commit
  35. 10 Aug, 2020 1 commit
  37. 06 Aug, 2020 2 commits
  39. 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
      93fce3f4
  41. 30 Jul, 2020 1 commit