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>
It was strange that the accented letters Ž and ž can be composed with
sequences that start with "v" ("v Z" and "v z"), but not Č and č and
Š and š (and other letters with a caron). For these letters, compose
sequences that start with a "c" had to be used, which was frustrating
because it is hard to remember that "c" stands for "caron", AND the
graphically more obvious "v" is right next to it.
(Unfortunately, the sequence "v l" is already taken for vertical line.
Maybe the compose sequences for vertical line could be reduced to just
"V L" and "L V"?)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
These artificial languages are meant to be international and are
thus not specific to any country. If one would want to support
aliases like ia_FR or ia_CH, then one would also have to support
ia_AU, ia_DE, ia_ES, et cetera, et cetera. That would be silly.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
They were found with:
while read one two; do
if [[ $one == $two: ]]; then echo $two; fi;
done <nls/locale.alias.pre
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
This function complements XSetIOErrorHandler(), allowing to override
the default behavior that trusts on I/O errors never coming back
(i.e. exit()ing the process).
This is meant as a mechanism for Wayland compositors (that are too
a X11 client + compositing manager) to unfasten seatbelts and jump
through the car window. It might get lucky and land on a stack of
pillows.
In consequence, some functions labeled as _X_NORETURN can as a
matter of fact return. So those hints were removed.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Ensure current state is cut short on _XIOError(), possible reentrancy
should be skipped through the XlibDisplayIOError flag checks.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
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.
If the compiler knows of a better algorithm for counting the number of
bits set in a word for the target CPU, let it use that, instead of the
classic algorithm optimized for PDP-6.
Based on libXext commit 490a25e6f8a4d2482af4364c700b68ad11a4d10b
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
