There was an "EXT" in the original text, but it seems to be missing.
See: 4e66da0783/specs/XIM/xim.ms (L693)
Signed-off-by: Hodong Kim <hodong@nimfsoft.com>
Assume event queue is empty if another thread is blocking waiting for event.
If one thread was blocking waiting for an event and another thread sent a
reply to the X server, both threads got blocked until an event was
received.
Signed-off-by: Tatu Frisk <tatu.frisk@ge.com>
Signed-off-by: Jose Alarcon <jose.alarcon@ge.com>
When _XGetRequest() detects that requested length exceeds remaining display
output buffer capacity it would return NULL. GetResReq() macro obtains "req"
pointer from a call to _XGetRequest() and then proceeds to assign request id
through "req" pointer which leads to NULL pointer dereference in this case.
Fix this by checking if "req" is valid before assigning request id.
Signed-off-by: Igor V. Kovalenko <igor.v.kovalenko@gmail.com>
These keys are all defined through a macro in the form:
#define XF86XK_BrightnessAuto _EVDEVK(0x0F4)
The _EVDEVK macro is simply an offset of 0x10081000.
Let's parse these lines correctly so those keysyms end up in our
hashtables.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Adding the offset between the realloc result and the old allocation to
update pointers into the new allocation is undefined behaviour: the
old pointers are no longer valid after realloc() according to the C
standard. While this works on almost all architectures and compilers,
it causes problems on architectures that track pointer bounds (e.g.
CHERI or Arm's Morello): the value_list pointers will still have the
bounds of the previous allocation and therefore any dereference will
result in a run-time trap.
I found this due to a crash (dereferencing an invalid capability) while
trying to run `xev` over SSH on a CHERI-RISC-V system. With these two
realloc changes, and https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/41
I am able to succesfully run `xev` compiled for CHERI-RISC-V.
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
We can't use `LC_CTYPE=C sed` there since /usr/bin/sed is not compatible
with the expressions in nls/ (`sed: RE error: illegal byte sequence`).
To fix this use $(SED) instead which autotools will set to a GNU
version of sed (usually /usr/local/bin/gsed) on macOS.
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
Checking against upper limit of USHRT_MAX must happen before truncating
size_t to int. On 64 bit systems with strings larger than 2 GB this
could otherwise lead to negative ints or ints smaller than USHRT_MAX.
In XParseColor this could lead to out of boundary access with strings
starting with a # (color sequence). A modulo 12 operation is performed
to validate the string length, but with an overflown length, the for
loop would eventually read behind terminating '\0' character.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Array `keysym_to_unicode_590_5fe` is only valid for range [0x590, 0x5fe] but current lower-bound is checked against 0x589.
So invalid values from 0x58a to 0x58f are being allowed by current check.
If any of these invalid value is passed as `keysym`, `keysym - 0x590` would underflow.
Signed-off-by: Gaurav Ujjwal <gujjwal00@gmail.com>
Commit 0bbc0d5e60 (from eight years ago) removed the lines that two
of these comments referred to. Without those lines, the comments don't
make sense any more. Reword and shorten them.
Also reword a comment about two sequences that don't work.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The letters ă and ŭ can already be composed with "u a" and "u u", but
ĕ, ğ, ĭ, and ŏ can be composed only with an uppercase U. Emancipate
the latter four and understand also a lowercase "u" to mean 'breve'.
(Yesterday I needed ğ and was annoyed that "u g" did not work.)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
this was found by checking man pages with
groff -t -mandoc -Z -wmac -Tutf8 $FILE >/dev/null
In most cases .hN could be replaced with .BR
Signed-off-by: Walter Harms <wharms@bfs.de>
The missing macro is found via:
roff -t -mandoc -Z -wmac -Tutf8 XAnyEvent.man >/dev/null
To fix the problem the macro is replaced with .RB.
Signed-off-by: Walter Harms <wharms@bfs.de>
The normal form is 'C.UTF-8', but 'C.utf8' has been seen in the wild.
Fixes#102.
Reported-by: Tomas Korbar
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
While these are mostly called during teardown of larger structures
that are about to themselves be freed, there's no guarantee that
will always be the case, so try to be safer here.
[ This bug was found by the Parfait 4.0 bug checking tool.
http://labs.oracle.com/pls/apex/f?p=labs:49:::::P49_PROJECT_ID:13 ]
v2: Deduplicate & simplify pointer clearing in _XFreeEventCookies
as suggested by @keithp
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Resolves parfait warning of potential macro misinterpretation if
expanded in the midst of other arithmetic operations with higher
precedence.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Locale modifiers may be freed whenever XSetLocaleModifiers gets
called, even if the locale hasn't changed. This means that we cannot
save a pointer to those modifiers in the XimInstCallback record and
must, instead, make a copy of them instead.
This fixes a problem uncovered when running wish under libasan as
follows (on current Debian unstable):
$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6 wish
Reported-by: Vittorio Zecca <zeccav@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
v2:
Remove incorrect 'else' token found by @alanc
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 <peter.hutterer@who-t.net>
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
https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/34
Reworked primarily for readability by Peter Hutterer, see
https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/53
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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 <digetx@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Combining characters are not dead keys -- they have an immediate effect
and combine with the preceding character. So they cannot be used in
compose sequences.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Most locale context users call _XlcCurrentLC, which returns a pointer
which never needs to be passed to _XCloseLC, meaning it has unbounded
lifetime, so that locale data can never be freed.
Remove all reference counting and just leave all locales that were
ever used in memory.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Martin Peres <martin.peres@mupuf.org>
These functions were caching encoding conversion functions in static
variables which is not thread safe. Let the conversion loader do its
job and cache locale to converters there. It's less efficient, but
it's also (now) thread safe.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Martin Peres <martin.peres@mupuf.org>
