If the length of a message exceeds the maximum length of the buffer, the
buffer size will reach its maximum value and stay there forever, with no
message ever being successfully processed. Since libwayland uses
level-triggered epoll, this will cause the compositor to loop forever
and consume CPU time. In libwayland 1.22 and below, there was an
explicit check that caused messages exceeding 4096 bytes to result in an
EOVERFLOW error, preventing the loop. However, this check was removed
between d074d52902 ("connection: Dynamically resize connection buffers").
To prevent this problem, always limit the size of messages to 4096 bytes.
Since the default and minimum buffer size is 4096 bytes, this ensures
that a single message will always fit in the buffer. It would be
possible to allow larger messages if the buffer size was larger, but the
maximum size of a message should not depend on the buffer size chosen by
the compositor.
Rejecting messages that exceed 4092 bytes seems to have the advantage of
reserving 4 bits, not 3, in the size field for future use. However,
message sizes in the range [0x0, 0x7] are invalid, so one can obtain a
fourth bit by negating the meaning of bit 12 if bits 0 through 11
(inclusive) are 0. Allowing 4096-byte messages provides the far more
important advantage that regressions compared to 1.22 are impossible
and regressions compared to 1.23 are extremely unlikely. The only case
where a regression is possible is:
- The receiving side is using libwayland 1.23.
- The sending side is either using libwayland 1.23 or is not using
libwayland.
- The sender sends a message exceeding 4096 bytes.
- If the sender of the large message is the client, the server has
increased the buffer size from the default value.
This combination is considered extremely unlikely, as libwayland 1.22
and below would disconnect upon receiving such a large message.
4096-byte messages, however, have always worked, so there was no reason
to avoid sending them.
Fixes: d074d52902 ("connection: Dynamically resize connection buffers").
Fixes: #494
Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com>
(cherry picked from commit adf84614ca)
The paragraph later says that accessing different buffers is
allowed. The function checks whether the same pool is accessed.
Signed-off-by: Simon Ser <contact@emersion.fr>
Shared memory buffers are currently tied to the lifetime of their
underlying wl_buffer resource. This becomes problematic when the client
destroys the resource after committing new state which references the
wl_buffer because a compositor might have to defer applying the commit.
This commit adds methods to keep the wl_shm_buffer alive longer than the
underlying resource. This implicitly also keeps the buffer pool alive
and because the wl_shm_buffer uses offsets into the pool, it even works
when the underlying storage gets remapped somewhere else, which can
happen when the client resizes the pool.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
If the pool refcount reaches zero, it is freed, so accessing its members
is UB which ASan would catch.
Also simplify check for negative refcounts.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
This seems to have been the case since 2013.
This is useful for wrappers that need two pointers to identify proxies.
One pointer (stored in the user data) pointing to a singleton object to
identify that the proxy has a known structure. And one pointer (stored
in the dispatcher data) pointing to per-proxy data.
Signed-off-by: Julian Orth <ju.orth@gmail.com>
Generated XXX_is_valid() functions for enums are guarded behind the
same #define as the enum itself. This worked fine until recently,
but since fbd7460737 ("scanner: add new enum-header mode") we're
also generating enum-only headers.
When including the enum-only header first, and then the server
header, the validator functions are missing.
Define a separate guard to fix this.
Signed-off-by: Simon Ser <contact@emersion.fr>
The `timespec` struct is defined in `time.h` header but only if
`_POSIX_C_SOURCE` is set or when using the C11 standard.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Now that wl_fixed_from_double() calls round() from a function declared
in a header, our users need to explicitly pick that dependency up in
order to avoid build errors.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Closes: wayland/weston#991
For dispatching messages on a queue with a timeout.
This slightly changes the samantics of wl_display_dispatch. Previously
it was possible for it to return even though there wasn't a single
dispatched event. The function correctly returned 0 in this case but it
is now used to indicate a timeout.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
Makes it possible to e.g. `call wl_client_get_credentials` with a `const
struct wl_client *` from a global filter callback.
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
when cast double to fixed pointer, there will be big
error, eg 1919.9998 to 1919. Call round before cast
to get nearest value 1920 of 1919.9998
Signed-off-by: Haihua Hu <jared.hu@nxp.com>
Prevents undefined behavior if there is not enough space in the buffer
for a queued message.
Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com>
Creating a pointer that is more than one element past the end of an
array is undefined behavior, even if the pointer is not dereferenced.
Avoid this undefined behavior by using `p >= end` instead of
`p + 1 > end` and `SOMETHING > end - p` instead of
`p + SOMETHING > end`.
Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com>
libwayland cannot construct these messages as it uses strlen() to
determine string lengths. libwayland is also guaranteed to misinterpret
these messages, since message handlers only get a pointer and no length.
Therefore, reject strings containing NUL bytes.
Also remove a redundant check from the unmarshalling code. The
zero-length case has already been checked for.
Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com>
The log that appears before a display_error can be captured as crash
signature. Useful to know what it is.
This is cherry-picked from chromium https://crrev.com/c/4697877
Signed-off-by: Fangzhou Ge <fangzhoug@chromium.org>
From cleanup commit 0cecde304:
assert()s can be compiled away by #defining NDEBUG. Some build systems
do this. Using wl_abort gives a human readable error message and it
isn't compiled away.
That commit missed one final assert, presumably due to missing it with
grep because of a coding style issue. Fix that up, and remove inclusion
of <assert.h> as appropriate.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
wl_proxy_get_queue can return NULL if the queue of the proxy was already
destroyed with wl_event_queue_destroy. In this case, the queue also has
no name anymore.
Fixes: b42218f ("client: Allow setting names for queues")
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
assert()s can be compiled away by #defining NDEBUG. Some build systems
do this. Using wl_abort gives a human readable error message and it
isn't compiled away. This commit closes issue #230.
Signed-off-by: meltq <tejasvipin76@gmail.com>
Bitfields are valid if the value only contains bits inside of
the supported entries for the given version.
Signed-off-by: Simon Ser <contact@emersion.fr>
It's unclear whether one needs to call close() if wl_client_create()
fails. Hopefully this change makes it more clear.
Signed-off-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>
Currently WAYLAND_DEBUG text ignores events that have no listener.
It can be helpful to know when you're receiving unhandled events,
as you may have forgotten to add a listener, or adding a dispatch
may have magically seemed to fix code that doesn't appear to be
dispatching anything.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes the following warning:
src/wayland-client-core.h:125: warning: Found non-existing group 'wl_proxy' for the command '@ingroup', ignoring command
"\memberof" cannot be used here because it only works on functions.
The docs for "\memberof" say that "\relates" works in a similar way.
While at it, use a "\" command instead of a "@" command for
consistency with the rest of the file.
Signed-off-by: Simon Ser <contact@emersion.fr>
This marks a request, event or enum entry as deprecated since a
given version.
Note that it's not clear what it means if an entry is deprecated
at some version, and the enum is used from some completely different
interface than where it was defined. However, that's a more general
issue with enums, see:
https://gitlab.freedesktop.org/wayland/wayland/-/issues/435
Signed-off-by: Simon Ser <contact@emersion.fr>
References: https://gitlab.freedesktop.org/wayland/wayland/-/issues/89
Right now compositors need to manually check that enum values sent
by the client are valid. In particular:
- Check that the value sent by the client is not outside of the enum.
- Check that the version of the enum entry is consistent with the
object version.
Automatically generate validator functions to perform these tasks.
Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/104
When using fixed size connection buffers, if either the client or the
server is sending requests faster than the other end can cope with, the
connection buffers will fill up, eventually killing the connection.
This can be a problem for example with Xwayland mapping a lot of
windows, faster than the Wayland compositor can cope with, or a
high-rate mouse flooding the Wayland client with pointer events.
To avoid the issue, resize the connection buffers dynamically when they
get full.
Both data and fd buffers are resized on demand.
The default max buffer size is controlled via the wl_display interface
while each client's connection buffer size is adjustable for finer
control.
The purpose is to explicitly have larger connection buffers for specific
clients such as Xwayland, or set a larger buffer size for the client
with pointer focus to deal with a higher input events rate.
v0: Manuel:
Dynamically resize connection buffers - Both data and fd buffers are
resized on demand.
v1: Olivier
1. Add support for unbounded buffers on the client side and growable
(yet limited) connection buffers on the server side.
2. Add the API to set the default maximum size and a limit for a given
client.
3. Add tests for growable connection buffers and adjustable limits.
v2: Additional fixes by John:
1. Fix the size calculation in ring_buffer_check_space()
2. Fix wl_connection_read() to return gracefully once it has read up to
the max buffer size, rather than returning an error.
3. If wl_connection_flush() fails with EAGAIN but the transmit
ring-buffer has space remaining (or can be expanded),
wl_connection_queue() should store the message rather than
returning an error.
4. When the receive ring-buffer is at capacity but more data is
available to be read, wl_connection_read() should attempt to
expand the ring-buffer in order to read the remaining data.
v3: Thomas Lukaszewicz <tluk@chromium.org>
Add a test for unbounded buffers
v4: Add a client API as well to force bounded buffers (unbounded
by default (Olivier)
v5: Simplify ring_buffer_ensure_space() (Sebastian)
Co-authored-by: Olivier Fourdan <ofourdan@redhat.com>
Co-authored-by: John Lindgren <john@jlindgren.net>
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Signed-off-by: John Lindgren <john@jlindgren.net>
Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
Closes: https://gitlab.freedesktop.org/wayland/wayland/-/issues/237
This generates a header with only enum definitions. This is useful
to share enum headers between libraries and library users.
Signed-off-by: Simon Ser <contact@emersion.fr>
If a wl_array has size zero, wl_array_for_each computes NULL + 0 to get
to the end pointer. This should be fine, and indeed it would be fine in
C++. But the C specification has a mistake here and it is actually
undefined behavior. See
https://davidben.net/2024/01/15/empty-slices.html
Clang's -fsanitize=undefined flags this. I ran into this in Chromium's
build with wayland-scanner on one of our XML files.
../../third_party/wayland/src/src/scanner.c:1853:2: runtime error: applying zero offset to null pointer
#0 0x55c979b8e02c in emit_code third_party/wayland/src/src/scanner.c:1853:2
#1 0x55c979b89323 in main third_party/wayland/src/src/scanner.c
#2 0x7f8dfdb8c6c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#3 0x7f8dfdb8c784 in __libc_start_main csu/../csu/libc-start.c:360:3
#4 0x55c979b70f39 in _start (...)
An empty XML file is sufficient to hit this case, so I've added it as a
test. To reproduce, undo the fix and include only the test, then build
with:
CC=clang CFLAGS="-fno-sanitize-recover=undefined" meson build/ -Db_sanitize=undefined -Db_lundef=false
ninja -C build test
Signed-off-by: David Benjamin <davidben@google.com>
