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>
FreeBSD doesn't support mremap [1], so we have a fallback
implementation based on munmap+mmap. We memcpy from the old memory
region to the new one, however this is unnecessary because the new
mapping references the same file as the old one.
Use msync to make sure any pending write is flushed to the underlying
file before we map the new region.
[1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=59912
Signed-off-by: Simon Ser <contact@emersion.fr>
Commit 5a981ee8 implemented a fallback path for platforms which do not
support mremap() such as FreeBSD.
To do so, the file descriptor for the mmap() is not closed immediately
but instead kept as long as the pool exists.
That induces more file descriptors kept open for longer, which in turn
may cause problems as wl_shm may be using a lot of file descriptors,
especially with Xwayland which can create a lot of pixmaps on behalf of
its X11 clients.
For platforms where mremap() is available, keeping those file
descriptors opened is a bit of a waste and may cause exhaustion of file
descriptors sooner that before commit 5a981ee8.
Only keep the mmap() file descriptor open on platforms which do not
implement mremap() and close it immediately as before on others.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1283
Initialiaze the entire msghdr struct to 0 before use.
Example of the report fixed with this change:
AddressSanitizer:DEADLYSIGNAL
=================================================================
==20035==ERROR: AddressSanitizer: SEGV on unknown address 0x2dad4dbffffa0d (pc 0x0055555c7488 bp 0x007fffffc760 sp 0x007fffffc760 T0)
==20035==The signal is caused by a READ memory access.
#0 0x55555c7488 in read_msghdr(void*, __sanitizer::__sanitizer_msghdr*, long) (/home/ftrvx/w/_/uxn/bin/uxnemu+0x77488)
#1 0x55555c810c in sendmsg (/home/ftrvx/w/_/uxn/bin/uxnemu+0x7810c)
#2 0x7ff7f2db20 in wl_connection_flush /home/ftrvx/q/wayland/build/../src/connection.c:315:10
#3 0x7ff7f2d014 in wl_display_flush /home/ftrvx/q/wayland/build/../src/wayland-client.c:2154:9
#4 0x7ff7e80bc0 (/lib/libSDL2-2.0.so.0+0x104bc0)
#5 0x7ff7e523b0 (/lib/libSDL2-2.0.so.0+0xd63b0)
#6 0x7ff7e534e4 (/lib/libSDL2-2.0.so.0+0xd74e4)
#7 0x7ff7e535e8 (/lib/libSDL2-2.0.so.0+0xd75e8)
#8 0x7ff7daad54 (/lib/libSDL2-2.0.so.0+0x2ed54)
#9 0x7ff7dab130 (/lib/libSDL2-2.0.so.0+0x2f130)
#10 0x555565bb40 in main /home/ftrvx/w/_/uxn/src/uxnemu.c:519:2
#11 0x7ff7f62484 in libc_start_main_stage2 /builddir/musl-1.1.24/src/env/__libc_start_main.c:94:2
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/home/ftrvx/w/_/uxn/bin/uxnemu+0x77488) in read_msghdr(void*, __sanitizer::__sanitizer_msghdr*, long)
==20035==ABORTING
Signed-off-by: Sigrid Solveig Haflínudóttir <ftrvxmtrx@gmail.com>
wl_signal_emit doesn't handle well situations where a listener removes
another listener. This can happen in practice: wlroots and Weston [1]
both have private helpers to workaround this defect.
wl_signal_emit can't be fixed without breaking the API. Instead,
introduce a new function. Callers need to make sure to always remove
listeners when they are free'd.
[1]: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/457
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Not checking the result of wl_array_add() can cause writes past the end of the
allocated buffer if realloc fails.
Signed-off-by: Aleksandr Mezin <mezin.alexander@gmail.com>
When multiple threads are used, output from different threads was intermixed in one line. That what breaking parsing of the log messages. Now, intermixing is prevented by using a memstream.
Signed-off-by: Alexander Irion <alexander_irion@mentor.com>
When allocating memory for structs, use zalloc instead of malloc.
This ensures the memory is zero-initialized, and reduces the risk
of forgetting to initialize all struct fields.
Signed-off-by: Simon Ser <contact@emersion.fr>
