Currently it is possible to iterate over client-owned resources
during client destruction that have had their associated memory
released.
This can occur when client code calls wl_client_destroy(). The
following sequence illustrates how this may occur.
1. The server initiates destruction of the connected client via
call to wl_client_destroy().
2. Resource destroy listeners / destructors are invoked and
resource memory is freed one resource at a time [1].
3. If a listener / destructor for a resource results in a call
to wl_client_for_each_resource(), the iteration will proceed
over resources that have been previously freed in step 2,
resulting in UAFs / crashes.
The issue is that resources remain in the client's object map
even after they have had their memory freed, and are removed
from the map only after each individual resource has had its
memory released.
This patch corrects this by ensuring resource destruction first
invokes listeners / destructors and then removing them from the
client's object map before releasing the associated memory.
[1] https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/wayland-server.c?ref_type=heads#L928
Signed-off-by: Thomas Lukaszewicz thomaslukaszewicz@gmail.com
Allow setting a name for an event queue. The queue is used only for
printing additional debug information.
Debug output can now show the name of the event queue an event is
dispatched from, or the event queue of a proxy when a request is made.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Some code paths that lead to a client error and connection termination
have no associated logging, or insufficient logging. This makes it
difficult to understand what went wrong. This commit adds or supplements
logging for all these code paths.
Signed-off-by: Erik Chen <erikchen@chromium.org>
wl_connection_write() contained an exact copy of the logic in
wl_connection_queue(). Simplify things by just calling
wl_connection_queue() from wl_connection_write().
Signed-off-by: John Lindgren <john@jlindgren.net>
For libs/cflags this is done automatically, but not for manually accessed
variables. This matches what wayland-protocols does.
Signed-off-by: Andreas Cord-Landwehr <cordlandwehr@kde.org>
This was hardcoded to 1 regardless of the version passed to the
callback or the version of the parent resource.
Signed-off-by: Simon Ser <contact@emersion.fr>
Due to what is arguably a mistake in the C language specification,
passing NULL to memcpy and friends is undefined behavior (UB) even when
the count is 0. C additionally mistakenly leaves NULL + 0 and NULL -
NULL undefined. (C++ fixes this mistake.) These are very problematic
because (NULL, 0) is a natural representation of the empty slice.
Some details:
https://github.com/llvm/llvm-project/issues/49459https://www.imperialviolet.org/2016/06/26/nonnull.html
Unfortunately, despite how clearly this is a mistake, glibc headers and
GCC now try to exploit this specification mistake and will miscompile
code, so C projects need to workaround this. In particular, UBSan from
Clang will flag this as a bug (although Clang itself has the good sense
to never lean on this bug). We've run into a few UBSan errors in
Chromium stemming from Wayland's memcpy calls. Add runtime guards as
needed to avoid these cases.
Note: Chromium's copy of wayland has
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188
applied. It is possible the ring_buffer_copy UB cases are only reachable
with that MR applied, I'm not sure. But it seemed simplest to just add
the fix to wayland as-is. Then when/if that MR lands, it will pick this
up.
Signed-off-by: David Benjamin <davidben@google.com>
This can be useful for additional validation purposes when handling
proxies. This is similar to existing server side API
wl_global_get_display.
Signed-off-by: David Edmundson <david@davidedmundson.co.uk>
Wayland debug logs resemble email addresses. This is a problem when
anonymizing logs from users. For example:
[2512874.343] xdg_surface@700.configure(333)
In the above log line, the substring "surface@700.config" can be
mistaken for an email address and redacted during anonymization.
Signed-off-by: Alex Yang <aycyang@google.com>
The way we're wrapping libc functions via dlsym() is pretty fragile
and breaks on FreeBSD. The failures happen in our CI and are pretty
random, see e.g. [1].
Use a more manual way to wrap via a function pointer.
[1]: https://gitlab.freedesktop.org/wayland/wayland/-/jobs/44204010
Signed-off-by: Simon Ser <contact@emersion.fr>
Use bool instead of int for boolean values, to make it more
explicit what the field contains. For instance "error" is not to
be confused with an error code.
This is all private API.
Signed-off-by: Simon Ser <contact@emersion.fr>
If wl_event_loop_dispatch() fails, we could enter an infinite loop,
repeatedly calling a failing wl_event_loop_dispatch() forever.
Signed-off-by: Simon Ser <contact@emersion.fr>
the 'has_timers' flag can be returned directly without having to track all the ready events
when a timer is found ready.
Signed-off-by: Yang Wang <KevinYang.Wang@amd.com>
This fixes an issue where it was not possible to start Gamescope under GDB on some setups.
https://github.com/ValveSoftware/gamescope/issues/743
Any signals would cause epoll_wait to return -1 and set errno to EINTR.
This also handles the EAGAIN case like the other polling loops in libwayland.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
If the default queue is being destroyed, the client is disconnecting
from the wl_display, so there is no possibility of subsequent events
being queued to the destroyed default queue, which is what this warning
is about.
Note that interacting with (e.g., destroying) a wl_proxy after its
wl_display is destroyed is a certain memory error, and this warning will
indirectly warn about this issue. However, this memory error should be
detected and warned about through a more deliberate mechanism.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Detect when we are trying to add an event to a destroyed queue,
and abort instead of causing a use-after-free memory error.
This situation can occur when an wl_event_queue is destroyed before
its attached wl_proxy objects.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Log a warning if the queue is destroyed while proxies are still
attached, to help developers debug and fix potential memory errors.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Maintain a list of all wl_proxy objects that are attached to a
wl_event_queue. We will use this information in upcoming commits to warn
about improper object destruction order that can lead to memory errors.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
With wl_shm_buffer_ref_pool(), it's possible for a wl_shm_pool
to outlive its wl_resource. We need to be careful not to access
wl_shm_pool.resource if it's been destroyed.
Reset resource to NULL in the resource destroy handler, and add
NULL checks.
Signed-off-by: Simon Ser <contact@emersion.fr>
display->id is initialized to 1, making 0 a convenient value to
indicate an invalid global name. Make sure to not return a zero
global name on overflow. Moreover, if we wrap around, we might
cycle back to a global name which is already in-use.
Signed-off-by: Simon Ser <contact@emersion.fr>
According to clang, qsort cannot be passed a null pointer, even if the size is
specified to be zero. The scanner can hit this while trying to sort forward
declarations if it happens to be building a protocol file that doesn't require
any, either in the header or the source.
Signed-off-by: Fergus Dall <sidereal@google.com>
A late-destroy listener for a client is called after all the client's
resources have been destroyed and the destroy callbacks emitted. This
lives in parallel to the existing client destroy listener, called
immediately before the client's objects get destroyed.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: wayland/wayland#207
Fixes the following warnings:
src/wayland-server.c:1152: warning: documented empty return type of wl_display::wl_display_destroy
src/wayland-server.c:1193: warning: documented empty return type of wl_display::wl_display_set_global_filter
Signed-off-by: Simon Ser <contact@emersion.fr>
Doxygen doesn't support documenting unnamed function arguments.
Fixes the following warnings:
src/wayland-util.h:697: warning: argument 'const' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'void' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'void' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'uint32_t' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'const' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'struct' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'wl_message' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'union' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'wl_argument' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:725: warning: argument 'const' of command @param is not found in the argument list of wl_log_func_t(const char *, va_list)
src/wayland-util.h:725: warning: argument 'char' of command @param is not found in the argument list of wl_log_func_t(const char *, va_list)
src/wayland-util.h:725: warning: argument 'va_list' of command @param is not found in the argument list of wl_log_func_t(const char *, va_list)
src/wayland-util.h:697: warning: argument 'const' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'void' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'void' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'uint32_t' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'const' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'struct' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'wl_message' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'union' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:697: warning: argument 'wl_argument' of command @param is not found in the argument list of wl_dispatcher_func_t(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)
src/wayland-util.h:725: warning: argument 'const' of command @param is not found in the argument list of wl_log_func_t(const char *, va_list)
src/wayland-util.h:725: warning: argument 'char' of command @param is not found in the argument list of wl_log_func_t(const char *, va_list)
src/wayland-util.h:725: warning: argument 'va_list' of command @param is not found in the argument list of wl_log_func_t(const char *, va_list)
Signed-off-by: Simon Ser <contact@emersion.fr>
Typically this is a number between 0 and 32. Just that the compiler doesn't
know that well. Make the string buffer a bit larger, so that it fits the
longer integers. Fixes build warnings like:
../subprojects/wayland/src/wayland-server.c: In function ‘wl_display_add_socket_auto’:
../subprojects/wayland/src/wayland-server.c:1649:70: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 8 [-Werror=format-truncation=]
1649 | snprintf(display_name, sizeof display_name, "wayland-%d", displayno);
| ^~
../subprojects/wayland/src/wayland-server.c:1649:61: note: directive argument in the range [-2147483647, 32]
1649 | snprintf(display_name, sizeof display_name, "wayland-%d", displayno);
| ^~~~~~~~~~~~
../subprojects/wayland/src/wayland-server.c:1649:17: note: ‘snprintf’ output between 10 and 20 bytes into a destination of size 16
1649 | snprintf(display_name, sizeof display_name, "wayland-%d", displayno);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Seen in GTK CI.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
The usefulness of this is limited, and `libwayland-client` doesn't
provide a way to pass a null `new_id` since the id is generated by the
library and given to the caller as the return value.
Signed-off-by: Ian Douglas Scott <idscott@system76.com>
Nullable arrays, which are not used anywhere, were marshalled the same
way as an empty non-null array. The demarshalling logic did not
recognize anything as a null array. Given this, it seems better to just
explicitly not support it.
Fixes https://gitlab.freedesktop.org/wayland/wayland/-/issues/306.
Signed-off-by: Ian Douglas Scott <idscott@system76.com>
Callers may check errno when wl_map_insert_* functions return an
error (since [1]). Make sure it's always set to a meaningful value
when returning an error, otherwise callers might end up checking an
errno coming from a completely different function.
[1]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/205
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: b19488c715 ("util: Limit size of wl_map")
See the previous discussion at [1]: libwayland incorrectly skips
the visibility checks when sending global/global_remove events.
The check is only performed when a client performs a
wl_display.get_registry request.
[1]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/148
Signed-off-by: Simon Ser <contact@emersion.fr>
Assignments to a wl_proxy's queue member are currently not synchronized
with potential reads of that member during event reading/queuing.
Assuming atomic pointer value reads and writes (which is a reasonable
assumption), and using the documented best practices to handle event
queue changes, a queue change should still be safe to perform.
That being said, such implicitly atomic accesses are difficult to assess
for correctness, especially since they do not introduce memory barriers.
To make the code more obviously correct, and handle any potential races
we are not currently aware of, this commit updates wl_proxy_set_queue()
to set the proxy's event queue under the display lock (all other
proxy queue accesses are already done under the display lock).
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Document the proper way to deal with event queue changes, in order to
guarantee proper handing of all events which were queued before the
queue change takes effect, especially in multi-threaded setups.
Make a special note about queue changes of newly created proxies,
which require the use of a proxy wrapper for thread safety.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The [spec][1] reads:
> All paths set in these environment variables must be absolute. If an
> implementation encounters a relative path in any of these variables it should
> consider the path invalid and ignore it.
and
> If $XDG_DATA_HOME is either not set or empty, a default equal to
> $HOME/.local/share should be used.
Testing that the path is absolute also entails that is is non-empty.
[1]: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
Signed-off-by: Antonin Décimo <antonin.decimo@gmail.com>
This allows projects to use Wayland as a Meson subproject and get the
wayland-scanner executable when doing find_program('wayland-scanner').
Signed-off-by: Xavier Claessens <xavier.claessens@collabora.com>
Add a helper to check the advertised version of a global. This can
be handy when checking whether a compositor feature is supported,
instead of having to store the version passed to wl_global_create
separately.
Signed-off-by: Simon Ser <contact@emersion.fr>
Since server IDs are basically indistinguishable from really big client
IDs at many points in the source, it's theoretically possible to overflow
a map and either overflow server IDs into the client ID space, or grow
client IDs into the server ID space. This would currently take a massive
amount of RAM, but the definition of massive changes yearly.
Prevent this by placing a ridiculous but arbitrary upper bound on the
number of items we can put in a map: 0xF00000, somewhere over 15 million.
This should satisfy pathological clients without restriction, but stays
well clear of the 0xFF000000 transition point between server and client
IDs. It will still take an improbable amount of RAM to hit this, and a
client could still exhaust all RAM in this way, but our goal is to prevent
overflow and undefined behaviour.
Fixes#224
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fail when tests/documentation is enabled without libraries. Fail
when neither scanner nor libraries is enabled, because we don't
build anything in that case.
Signed-off-by: Simon Ser <contact@emersion.fr>
