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>
Client message observers 6/6
When the client code receives an event message for an unknown (or zombie)
object, the code was logging a message only to stderr, and only if debug_client
was set.
Introduce a helper function to create some temporary wl_closure and related
structures so that the unknown message can be sent out using the new client
observer API. This allows the client implementation to potentially log it
somewhere more useful than to just stderr, and it can register an observer at
any time too.
Note that the message that is logged is now structured slightly differently,
though it contains the same content.
Signed-off-by: Lloyd Pique <lpique@google.com>
Client message observers 5/6
When given an array of wl_arguments for a wl_closure, the .o field is an
opaque wl_object pointer, which the server implementation cannot really do
anything with, without a potentially unsafe cast that assumes details about the
internal implementation.
By adding a wl_resource_from_object() function to the client interface, the client
can safely get the wl_resource pointer.
This can be used by server protocol loggers in particular to get the resource id
and class name, for logging those details
Signed-off-by: Lloyd Pique <lpique@google.com>
Client message observers 4/6
When given an array of wl_arguments for a wl_closure, the ".o" field is an
opaque wl_object pointer, which the client code cannot really do anything with,
without a potentially unsafe cast that assumes details about the internal
implementation.
By adding a wl_proxy_from_object() function to the client interface, the client
can safely get the wl_proxy pointer.
This can be used by client message observers in particular to get the proxy id
and class name, for logging those details.
Signed-off-by: Lloyd Pique <lpique@google.com>
Client message observers 2/6
Introduce a client message observer interface, strongly resembling the server
protocol logger interface added in commit 450f06e2.
This means a new pair of public API functions:
* wl_display_create_client_observer(): allows a client to register an observer
function, which is called for messages that are received or sent.
* wl_client_observer_destroy() which destroys the observer created by the prior
function.
With these changes, a client can set and clear an observer at run-time, and can
use it to log client messages to a location other than stderr.
The existing protocol-logger-test has also been revised and extended to demonstrate
using the new API for test use, to validate the sequence of messages sent and
received by the client, on top of the existing checks to do the same for the
server messages.
Signed-off-by: Lloyd Pique <lpique@google.com>
Client message observers 1/6
Cleans up wl_closure_print(), and adds a client-private closure_log()
intermediate function.
This patch simplifies wl_closure_print() slightly by moving some client-only
details to a new closure_log() intermediate function. This new function will
also handle delivering messages to the new listener callback in a subsequent
patch.
closure_log() internally handles the check for logging being enabled,
simplifying its callers, and returns early if logging is not enabled. This check
becomes a bit more complex when there can be listeners.
closure_log() also handles the work same transformation performed by
id_from_object(), by making a copy of the args, and applying the transform to
the copy before passing the arguments to wl_closure_print(). Doing it this way
means the same arguments can also be passed to the eventual listeners.
The boolean "discarded" argument for wl_closure_print() has been replaced by a
"discarded_reason" string argument, allowing an arbitrary reason string to be
passed in. For now only "discarded[]" is printed as an empty reason string is
passed if the message was discarded, but that will also change.
Signed-off-by: Lloyd Pique <lpique@google.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>
This is less cryptic to read than letters, and allows the compiler
to check switch statements exhaustiveness.
Signed-off-by: Simon Ser <contact@emersion.fr>
There are situations in which a call into wl_client_destroy() can
result in a reentrant call into wl_client_destroy() - which
results in UAF / double free crashes.
For example, this can occur in the following scenario.
1. Server receives a message notifying it that a client has
disconnected (WL_EVENT_HANGUP [1])
2. This beings client destruction with a call to wl_client_destroy()
3. wl_client_destroy() kicks off callbacks as client-associated
resources are cleaned up and their destructors and destruction
signals are invoked.
4. These callbacks eventually lead to an explicit call to
wl_display_flush_clients() as the server attempts to flush
events to other connected clients.
5. Since the client has already begun destruction, when it is
reached in the iteration the flush fails wl_client_destroy()
is called again [2].
This patch guards against this reentrant condition by removing
the client from the display's client list when wl_client_destroy()
is first called. This prevents access / iteration over the client
after wl_client_destroy() is called.
In the example above, wl_display_flush_clients() will pass over
the client currently undergoing destruction and the reentrant
call is avoided.
[1] 8f499bf404/src/wayland-server.c (L342)
[2] 8f499bf404/src/wayland-server.c (L1512)
Signed-off-by: Thomas Lukaszewicz [thomaslukaszewicz@gmail.com](mailto:thomaslukaszewicz@gmail.com)
- wayland-egl-abi-check: try to use llvm-nm first instead of BSD nm (incompatible options)
- avoid forcing _POSIX_C_SOURCE=200809L (SOCK_CLOEXEC become available)
- epoll(7) is provided by a userspace wrapper around kqueue(2) as FreeBSD
- when using SO_PEERCRED, the struct to use is `struct sockpeercred` instead of `struct ucred` on OpenBSD
- provide a compatibility layer for count_open_fds() using sysctl(2) as FreeBSD
Signed-off-by: Sebastien Marie <semarie@online.fr>
The only way to attach some data to a wl_client seems to be setting up a
destroy listener and use wl_container_of. Let's make it straight forward
to attach some data.
Having an explicit destroy callback for the user data makes managing the
user data lifetime much more convenient. All other callbacks, be they
wl_resource request listeners, destroy listeners or destructors, or
wl_client destroy listeners, can assume that the wl_client user data
still exists if it was set. Otherwise making that guarantee would be
complicated.
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Sebastian Wick <sebastian@sebastianwick.net>
