A head may have its output protection set before it is attached to an
output. Recompute the output protection whenever a head is attached to
make sure it correctly set in output.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
This skips over xdg-shell v4, which can be implemented with no changes
as it's just another optional event.
v5 adds a capabilities event, which we send to inform clients of the
window manager's capabilities.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This protocol allows clients to create single-pixel RGBA buffers. Now
that we have proper support for these buffers internally within Weston,
we can expose them to clients.
This bumps the build container version, as we now depend on
wayland-protocols v1.26.
Signed-off-by: Daniel Stone <daniels@collabora.com>
We want to support staging protocols which have a version too, so don't
assume that anything versioned is unstable.
Signed-off-by: Daniel Stone <daniels@collabora.com>
There are many reasons why trying to handle malloc() returning NULL by
any other way than calling abort() is not beneficial:
- Usually malloc() does not return NULL, thanks to memory overcommit.
Instead, the program gets SIGSEGV signal when it tries to access the
memory.
- Trying to handle NULL will create failure paths that are impractical
to test. There is no way to be sure the compositor still works once
such path is actually taken.
- Those failure path will clutter the code, increasing maintenance and
development burden.
- Sometimes there just isn't a good way to handle the failure.
For more discussion, see the issue link below.
Closes: https://gitlab.freedesktop.org/wayland/weston/-/issues/631
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The definition of zalloc is trivial, so let's just have it here instead
of loading libweston/zalloc.h.
Now xalloc.h does not depend on any libweston header, which makes me
feel slightly better. It's more clean.
Who knows, maybe one day libweston/zalloc.h will be removed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This file relied on shared/xalloc.h to include <libweston/zalloc.h>.
That would be a problem if xalloc.h stopped doing that.
Just use xzalloc().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Recently I learnt that fprintf() is not async-signal-safe. Maybe it also
attempts to allocate memory sometimes. Hence, using it when we
presumably are out of memory is wishful thinking.
Therefore replace that with async-signal-safe code. If you have to check
pointers from traditional signal handlers, now you could do that too!
While doing this, we also lose the string formatting for line number. I
would argue that printing file and line number is not that useful, if
the system really is out of memory. If not out of memory, a core dump
would give us much more detailed information about what went wrong.
clients/window.c had some calls to fail_on_null() and these are simply
replaced. They were used for checking that creating new wl_proxy by
issuing a protocol request worked, and IIRC that only fails on
out-of-memory, so the same rationale applies here.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Drop the even more home-grown alloc wrapper and use the xalloc.h
wrappers directly.
xcalloc() is added and used, because calloc() will detect integer
overflows in the size multiplication, while doing a simple
multiplication in the caller is subject to overflows which may result in
allocating not what was expected, subjecting to out-of-bounds access.
All MEM_ALLOC() calls that had a meaningful multiplication in them were
converted to xcalloc(), the rest to xzalloc().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
If we leave xwayland in weston's process group, it can receive
signals from the controlling TTY intended for weston.
The easiest way to see this is to launch weston under gdb, start an
X client, and hit ctrl-c in the gdb session. The Xwayland server
will also catch the SIGINT, and the X client will be disconnected.
Instead, let's call setsid() when launching Xwayland, like we do
for launched clients.
Suggested-by: Hideyuki Nagase <hideyukn@microsoft.com>
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
[common equivalent of 77cf8cb006 in Xwayland from Pekka Paalanen; its
commit message follows]
Between fork() and exec() in the child process it is only safe to use
async-signal-safe functions. weston_log() definitely is not one, it
allocates memory and does whatnot.
weston_log() is also inappropriate for other reasons: the child process
has its own stream buffers and flight-recorder. No-one looks into the
child process' flight recorder, so messages would be lost there. The
logging machinery might also attempt to write into debug streams,
meaning both parent and child could be writing simultaneously.
It seems that the best we can do is to pre-bake an error message and
only write() it out if exec() fails. There is no mention that even
strerror_r() might be safe to call, so we don't.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Use the custom_env framework we added for Xwayland when forking to
execute clients. This avoids calling the unsafe getenv in between fork
and exec.
Signed-off-by: Daniel Stone <daniels@collabora.com>
It was only a small function, and inlining it will allow us to make it
more safe without having to duplicate a ton of stuff.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This doesn't actually stop us from calling setenv() in between fork()
and exec() when starting clients, but gets us closer to Xwayland's safe
implementation by reusing one of the helpers it added.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Use the arg handling added in the previous commit so that the
environment is completely encapsulated inside the custom env.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rather than open-coding our own implementation of parsing a string to
construct an envp and an argp, just use custom_env's implementation.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Users like desktop-shell want to parse a provided string containing a
combination of environment and arg, e.g.: ENV=stuff /path/to/thing --good
Add support to custom-env for parsing this, with tests, so we can delete
the custom implementation inside desktop-shell.
Signed-off-by: Daniel Stone <daniels@collabora.com>
execve() takes the same form for arguments as environment: an array of
constant pointers to mutable strings, terminated by a NULL.
To make it easier for users who want to build up their own argument
strings to pass to execve, add support for argument arrays to custom_env.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Test the basic stuff: initialising from a known environment, setting a
new variable, overwriting a previous variable, and getting the resulting
array to pass to execve.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Rename the bits handling environment variables (currently, all of it),
so we have room to handle args as well.
No functional changes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This patch acts as bandaid in the core compositor to avoid the renderer
doing a flush after the buffer has been released. Flushing after release
can happen due to problems in the internal damage tracking, is violating
the protocol, and causes visible glitches.
A more proper fix would be to handle compositor side damage correctly.
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Acked-by: Daniel Stone <daniel.stone@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Since b38b735e20, 'backend-drm: Remove Pixman conditional
for keep_buffer' the Pixman renderer keeps its own reference to buffers
when attached to surfaces, rather than flipping keep_buffer variable for
the surface. Problem is that when switching from the Pixman render to
the GL would not work and could result in a crash upon first repaint.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Between fork() and exec() in the child process it is only safe to use
async-signal-safe functions. Painfully, setenv() is not listed as such.
Therefore we must craft our own custom environment, and we get no help
from libc with that.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Constructing argv before-hand is a little easier to look at, but this is
mostly just anticipating more changes to how Weston spawns processes in
general.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We are already using pipe2() in many places, even in libweston, so let's
simplify the code here as well - not to mention avoid a theoretical
race.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Between fork() and exec() in the child process it is only safe to use
async-signal-safe functions. Surprisingly, snprintf() is not such
function. See e.g. https://stackoverflow.com/a/6771799 and how snprintf
is not listed in signal-safety(7) manual.
Therefore we must prepare the fd argument strings before fork(). That is
only possible if we also do not dup() fd in the child process. Hence we
remove the close-on-exec flag instead in the child process which has
copies of the parent's file descriptors. Fortunately fcntl() is safe.
struct fdstr is helping to reduce code clutter a bit.
Additionally, if fork() fails, we now clean up the fds we created.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This function will be used between fork() and exec() to remove the
close-on-exec flag. The first user will be compositor/xwayland.c.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
fcntl(2) manual says the return type is int, and that F_SETFD takes an
int. So use int.
Noticed by code inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Between fork() and exec() in the child process it is only safe to use
async-signal-safe functions. weston_log() definitely is not one, it
allocates memory and does whatnot.
weston_log() is also inappropriate for other reasons: the child process
has its own stream buffers and flight-recorder. No-one looks into the
child process' flight recorder, so messages would be lost there. The
logging machinery might also attempt to write into debug streams,
meaning both parent and child could be writing simultaneously.
It seems that the best we can do is to pre-bake an error message and
only write() it out if exec() fails. There is no mention that even
strerror_r() might be safe to call, so we don't.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Doing any kind of memory allocation calls between fork() and exec() in
the child process is prone to deadlocks and explosions. In general, only
async-signal-safe functions are safe there.
Move the config access to the parent process before fork() to avoid
problems.
See also:
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/941#note_1457053
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This reverts commit 4aa885d4af.
Turns out the problem was not about dupping fds at all, but calling
non-async-signal-safe functions like strdup() between fork() and exec()
in the child process.
For more discussion, see:
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/941#note_1457053
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This patch fixes the following:
AddressSanitizer:DEADLYSIGNAL
=================================================================
==528956==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7fbc5d66bdd7 bp 0x7ffd465573c0 sp 0x7ffd46557398 T0)
==528956==The signal is caused by a WRITE memory access.
==528956==Hint: address points to the zero page.
#0 0x7fbc5d66bdd7 in wl_list_remove ../../git/wayland/src/wayland-util.c:56
#1 0x7fbc5cb8869e in wxw_compositor_destroy ../../git/weston/compositor/xwayland.c:357
#2 0x7fbc5baf3ca6 in weston_signal_emit_mutable ../../git/weston/shared/signal.c:62
#3 0x7fbc5ba4d6f9 in weston_compositor_destroy ../../git/weston/libweston/compositor.c:8639
#4 0x7fbc5cb7a5f2 in wet_main ../../git/weston/compositor/main.c:3772
#5 0x55bd13de2179 in main ../../git/weston/compositor/executable.c:33
#6 0x7fbc5be61d09 in __libc_start_main ../csu/libc-start.c:308
#7 0x55bd13de2099 in _start (/home/pq/local/bin/weston+0x1099)
The problem is triggered by configuring a bad path to Xwayland in
weston.ini, which causes exec() to fail. The fork() succeeded though,
which means the weston_process was already on the watch list, and the
watch can be handled, making sigchl_handler() leave the link
uninitialized.
Making sure the link remains removable fixes this.
Fixes: 18897253d4
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
While developing the new color management, keeping these old plugins
working would require extra work. Let's deprecate these to see if anyone
cares about them, pending removal after the Weston 11.0.0 release.
CI will keep building these in the "Full build" configuration only. Doc
and no-GL builds are no different for these plugins, so there these are
no longer built.
See https://gitlab.freedesktop.org/wayland/weston/-/issues/634
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
There are two versions of WM_NORMAL_HINTS: the original pre-ICCCM
version (standardised by Xlib itself?) provides 15 elements of 32 bits
each, with the ICCCM v1 extending this by 3 additional elements.
Since the flags are enough to identify which elements are present, and
the structure is append-only, we only need to read the minimum length
between what the user provided and what we support.
Fixes a heap overrun found with ASan.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Setting up the arguments may consume some of the arguments, e.g. if we
provide a config file or extra modules, then the test harness is
expected to be responsible for freeing those arguments.
Checking the requirements and bailing first means that we never do that,
and thus skipped tests result in leaks. Flip the order so we set up the
args first and skip last, so we can consistently take ownership of all
the provided setup parameters.
Signed-off-by: Daniel Stone <daniels@collabora.com>
ZUC's default mode is to fork for every test case. Unfortunately on
AArch64, fork in an ASan-traced program usually takes around 3.6 entire
seconds. This was leading to the config-parser test timing out.
As none of our remaining ZUC tests even need to fork, just remove all
support for it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
This commit is truly horrible.
We want to run ASan with leak checking enabled in CI so we can catch
memory leaks before they're introduced. This works well with Pixman, and
with NIR-only drivers like iris or Panfrost.
But when we run under llvmpipe - which we do under CI - we start failing
because:
- Mesa pulls in llvmpipe via dlopen
- llvmpipe pulls in LLVM itself via DT_NEEDED
- initialising LLVM's global type/etc systems performs thread-local
allocations
- llvmpipe can't free those allocations since the application might
also be using LLVM
- Weston stops using GL and destroys all GL objects, leading to Mesa
unloading llvmpipe like it should
- with everything disappearing from the process's vmap, ASan can no
longer keep track of still-reachable pointers
- tests fail because LLVM is 'leaking'
Usually, an alternative is to LD_PRELOAD a shim which overrides
dlclose() to be a no-op. This is not usable here, because when
$LD_PRELOAD is not empty and ASan is not first in it, ASan immediately
errors out. Prepending ASan doesn't work, because we run our tests
through Meson (which also invokes Ninja), leading to LSan exploding
over CPython and Ninja, which is not what we're interested in.
It would be possible to inject _both_ ASan and a dlclose-does-nothing
shim DSO into the LD_PRELOAD environment for every test, but that seems
even worse, especially as Meson strongly discourages globbing for random
files in the root.
So, here we are, doing what we can: finding where swrast_dri.so (aka
llvmpipe) lives, stashing that in an environment variable, and
deliberately leaking a dlopen handle which we never close to ensure that
neither llvmpipe nor LLVM leave our process's address space before we
exit.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Unfortunately just adding suppressions isn't enough; the build of Expat
we have in our CI system does not have frame pointers, so ASan's fast
unwinder can't see through it. This means that the suppressions we've
added won't be taken into account.
For now, disable the fast unwinder for the Xwayland test only. Disabling
it globally is not practical as it massively increases the per-test
runtime, so here (to avoid polluting the build system), we use a
per-test wrapper to selectively choose the unwinder.
Signed-off-by: Daniel Stone <daniels@collabora.com>
For some reason, the Debian CI setup leaks fontconfig allocations in a
way which it does not for me on Fedora. On the assumption that this has
been fixed between our older CI Debian and Fedora 36, suppress the leak
warning, because we do already call FcFini() which should free it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
When an output is destroyed then the output state is freed immediately. In this
case, the plane state is only partially destroyed because it is the currently
active state. This includes the buffer reference.
Without the output, the plane will not be updated any more until it is used by a
different output (if possible) or the output returns and the plane is used
again.
As a result, the buffer reference is kept for a long time. This will cause some
applications to stall because weston now keeps two buffers (the one here and
another one for a different output where the application is now displayed).
To avoid this, do a synchronous commit that disables the output. The output
needs to be disabled anyways and this way the current state contains no
buffers that would remain.
`device->state_invalid = true` in drm_output_detach_crtc() is no longer
needed, because drm_output_detach_crtc() is called only when initialization
failed and the crtc was not yet used or in drm_output_deinit() when the
crtc was already disabled with the new synchronous commit.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
