Previously each value was a list of extra sources. The next commit will add an
additional field to each test, so they need to be dicts themselves.
Signed-off-by: Matt Turner <mattst88@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>
Add tests which verify that...
* wl_display_dispatch_timeout with a big enough timeout behaves the same
as wl_display_dispatch
* wl_display_dispatch_timeout will time out when there are no messages
to dispatch
Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
Calling a function with the wrong type is immediate undefined behavior,
even if the ABI says it should be harmless. UBSAN picks it up
immediately, and any decent control-flow integrity mechanism will as
well.
Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.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>
Add a new event and enum entry to small.xml with a deprecated-since
attribute to exercise the scanner code generation.
Signed-off-by: Simon Ser <contact@emersion.fr>
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
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>
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>
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>
This adds a command to re-generate the test data. This needs to be
done when either an XML source file or the scanner's output is
changed.
Signed-off-by: Simon Ser <contact@emersion.fr>
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>
Because this benchmark performed wl_fixed_to_double conversions
on a long sequence of consecutive integers, the compiler could
optimize away the addition performed in wl_fixed_to_double, merging
it with the loop iteration code. This made tests/fixed-benchmark.c
significantly underestimate the actual cost of the current
wl_fixed_to_double implementation.
Signed-off-by: Manuel Stoeckl <code@mstoeckl.com>
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>
Add the display_destroy_expect_signal() function to check that test
clients exit due to a particular signal. This is useful for checking
that clients fail in an expected way.
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>
Capture the test client log to a temporary fd, so that is accessible by both
the test server process and the test client process.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Make sure that the client destroy handler runs strictly before the
resource destroy handler, which runs strictly before the client
late-destroy handler.
Signed-off-by: Daniel Stone <daniels@collabora.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
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>
Ensure dynamically created and destroyed globals which are filtered
don't trigger any global/global_remove event.
Signed-off-by: Simon Ser <contact@emersion.fr>
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>
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>
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>
Fixes the following warning:
WARNING: add_languages is missing native:, assuming languages are wanted for
both host and build.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes the following warning:
WARNING: Project targeting '>= 0.56.0' but tried to use feature deprecated
since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
Signed-off-by: Simon Ser <contact@emersion.fr>
Several tests in this suite use setting and checking client.display_stopped (in
test-compositor.h) to synchronise between threads. This is a data race because
display_stopped is a non-atomic int. Fix this by making it an atomic_bool
instead. We don't need to change the access code because reads and writes are
sequentially consistent by default.
This can be reproduced (with both clang and gcc) by running
```
meson -Db_sanitize=thread build
cd build
ninja
meson test
```
Signed-off-by: Fergus Dall <sidereal@google.com>
Currently libwayland assumes GNU extensions will be available, but
doesn't define the C standard to use. Instead, let's unconditionally
enable POSIX extensions, and enable GNU extensions on a case-by-case
basis as needed.
Signed-off-by: Simon Ser <contact@emersion.fr>
tc_client_fd_leaks and tc_client_fd_leaks_exec are currently the exact
same test. It seems clear from the name that the latter was intended to
spawn sanity_fd_leak_exec instead of sanity_fd_leak.
Fixes#121
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Calling wl_display_terminate() will exit the wl_display event loop
at the start of the next loop iteration. This works fine when
wl_display_terminate() is called after the event loop wakes up
from polling on the added event sources. If, however, it is
called before polling starts, the event loop will not exit until
one or more event sources trigger. Depending on the types of event
sources, they may never trigger (or may not trigger for a long time),
so the event loop may never exit.
Add an extra event source to the wl_display event loop that will trigger
whenever wl_display_terminate() is called, so that the event loop will
always exit.
Fixes#201
Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp>
On Linux the signal will be immediately visible in the epoll_wait() call.
However, on FreeBSD we may need a small delay between kill() call and the
signal being visible to the kevent() call. This sometimes happens when the
signal processing and kevent processing runs on different CPUs in the
kernel, so becomes more likely when the system is under load (e.g. running
all tests in parallel).
See https://github.com/jiixyj/epoll-shim/pull/32
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
If we are compiling against a version of FreeBSD where MSG_CMSG_CLOEXEC
does not work, use the fallback directly. This was only fixed recently
(in https://cgit.freebsd.org/src/commit/?id=6ceacebdf52211).
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
