I got a little over-eager with my sanity checks and didn't realize that the
client uses wl_map_insert_at to mark objects as zombies when they come from
the server-side.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
In order to use the second-lowest bit of each pointer in wl_map for the
WL_MAP_ENTRY_LEGACY flag, every pointer has to be a multiple of 4. This
was a good assumption, except with WL_ZOMBIE_OBJECT. This commit creates
an actual static variable to which WL_ZOMBIE_OBJECT now points. Since
things are only every compared to WL_ZOMBIE_OBJECT with "==" or "!=", the
only thing that matters is that it is unique.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
The implementation in this commit allows for one bit worth of flags. If
more flags are desired at a future date, then the wl_map implementation
will have to change but the wl_map API will not.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
The original wl_map implementation did no checking to ensures that ids fell
on the correct side of the WL_SERVER_ID_START line. This meant that a
client could send the server a server ID and it would happily try to use
it. Also, there was no distinction between server-side and client-side in
wl_map_remove. Because wl_map_remove added the entry to the free list
regardless of which side it came from, the following set of actions would
break the map:
1. Client creates a bunch of objects
2. Client deletes one or more of those objects
3. Client does something that causes the server to create an object
Because of the problem in wl_map_remove, the server would take an old
client-side id, apply the WL_SERVER_ID_START offset, and try to use it as a
server-side id regardless of whether or not it was valid.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Looking at the functionality in the server library, it's clear (in
hindsight) that there are two different "things" in there: 1) The IPC
API, that is, everything that concerns wl_display, wl_client,
wl_resource and 2) and half-hearted attempt at sharing input code and
focus logic that leaves a lot of problematic structs in the API
surface, only to share less than 1000 lines of code.
We can just move those input structs and helper functions into weston
and cut libwayland-server down to just the core server side IPC API.
In the short term, compositors can copy those structs and functions
into their source, but longer term, they're probably better off
reimplementing those objects and logic their native framework
(QObject, GObject etc).
If an unknown id is deleted then the lookup in the map will return NULL and
so we should avoid dereferencing that.
As this is unexpected behaviour log a message about the problem too.
Add a destroy listener so that when the current surface associated with the
pointer is destroyed we can reset the pointer to the current surface. In order
to achieve this add a wl_pointer_set_current() which handles assigning the
surface and creating the listener.
This resolves a use-after-free error triggered with nested popup surfaces
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=696946
use the wl_notify_func type, and not void *, or else wl_signal_get
will not be usable by a c++ plugin because it will not cast
void * to a function pointer.
Reorder the error handling in the case that closure is NULL due to ENOMEM to
ensure that we can safely call wl_closure_lookup_objects on the second test.
Prior to this reordering the closure would be deferenced in the ENOMEM case
due to the invocation of the second half of the logical OR check.
This commit adds a wl_resource_init function for initializing wl_resource
structures similar to wl_client_add_object.
From this commit forward, wl_resource structures should not be initialized
manually, but should use wl_resource_init. In the event of a change to the
wl_resource structure, this allows us to protect against regressions by filling
in added fields with reasonable defaults. In this way, while changing
wl_object or wl_resource still constitutes an ABI break, compositors following
this rule will only need to be recompiled in order to properly link against the
new version.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
This commit adds a flags parameter to wl_closure_invoke(). The so far
added flags are ment to specify if the invokation is client side or
server side. When on the server side, closure arguments of type 'new_id'
should be invoked as a integer id while on the client side they should
be invoked as a pointer to a proxy object.
This fixes a bug happening when the address of a client side 'new_id'
proxy object did not fit in a 32 bit integer.
krh: Squashed test suite compile fix from Jason Ekstrand.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
The llvm static analyzer tool reported "Use of memory after it is freed"
in dispatch_event() because the proxy is used after being freed if the
reference count reaches zero without the destroyed flag being set. This
would never happen in practice because the owner of the proxy object
always holds a reference until calling wl_proxy_destroy() which would
also set the destroyed flag.
Since this is the case, it is safe to do the reference count check only
if the destroyed flag is set, as it can never reach zero if not.
This commit doesn't change the behavior of the function, but makes the
static analyzer more happy.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=61385
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
The primary purpose of this patch is to clean up wl_closure and separate
closure storage, libffi, and the wire format. To that end, a number of changes
have been made:
- The maximum number of closure arguments has been changed from a magic number
to a #define WL_CLOSURE_MAX_ARGS
- A wl_argument union has been added for storing a generalized closure
argument and wl_closure has been converted to use wl_argument instead of the
combination of libffi, the wire format, and a dummy extra buffer. As of
now, the "extra" field in wl_closure should be treated as bulk storage and
never direclty referenced outside of wl_connection_demarshal.
- Everything having to do with libffi has been moved into wl_closure_invoke
and the convert_arguments_to_ffi helper function.
- Everything having to do with the wire format has been restricted to
wl_connection_demarshal and the new static serialize_closure function. The
wl_closure_send and wl_closure_queue functions are now light wrappers around
serialize_closure.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
This is a useful shorthand for client application debugging macros,
since you can ask the object class from the object itself.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This is there to enforce that we don't have interfaces with a destroy
request that isn't a destructor. The check never worked because of the
typo, but we also don't have any interfaces like that.
Most extra data are just pointers, but in case of fds we store an int in
the extra space. That can cause un-aligned access to pointers on 64 bit
architectures. Make sure we always align pointer storage correctly.
The need for wl_display_update_func_t was removed in
commit 53d24713a3
Author: Kristian Høgsberg <krh@bitplanet.net>
Date: Thu Oct 4 16:54:22 2012 -0400
Change filedescriptor API to be thread safe
and wl_callback_func_t does not seem to have ever been used in the first place.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The scanner would not allow two consecutive requests on an interface to
have the same since number, so if a new version of an interface added
two new request the version number would have to be increased by two.
Since wl_display_dispatch() returns the number of processed events or -1
on error, only cancel the roundtrip if an -1 is returned.
This also fixes a potential memory corruption bug happening when
wl_display_roundtrip() does an early return and the callback later
writes to the then out of scope stack allocated `done' parameter.
Introduced by 33b7637b45.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
On the client side EGL, all the wl_buffer.release events need to be
processed before buffer allocation, otherwise a third buffer might
be allocated unnecessarily. However, the buffer allocation should
not block in the case no event was received. In order to do that, a
non-blocking queue dispatch function is needed.
By default the server will dump protocol for both the server and its
clients when run with WAYLAND_DEBUG=1. That's still the case, but it now
also understands WAYLAND_DEBUG=client or WAYLAND_DEBUG=server, which
will only enable debug dumping on either client or server side.
When events are queued, the associated proxy objects (target proxy and
potentially closure argument proxies) are verified being valid. However,
as any event may destroy some proxy object, validity needs to be
verified again before dispatching. Before this change this was done by
again looking up the object via the display object map, but that did not
work because a delete_id event could be dispatched out-of-order if it
was queued in another queue, causing the object map to either have a new
proxy object with the same id or none at all, had it been destroyed in
an earlier event in the queue.
Instead, make wl_proxy reference counted and increase the reference
counter of every object associated with an event when it is queued. In
wl_proxy_destroy() set a flag saying the proxy has been destroyed by the
application and only free the proxy if the reference counter reaches
zero after decreasing it.
Before dispatching, verify that a proxy object still is valid by
checking that the flag set in wl_proxy_destroy() has not been set. When
dequeuing the event, all associated proxy objects are dereferenced and
free:ed if the reference counter reaches zero. As proxy reference counter
is initiated to 1, when dispatching an event it can never reach zero
without having the destroyed flag set.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
The _* namespace and identifiers with double underscore are reserved
by the C standard. That makes __wl_container_of is double plus bad,
so lets just call it wl_container_of.
Exporting unprefixed symbols is a pretty bad idea so don't do that.
Instea of redefining it WL_ARRAY_LENGTH, we just move the define to
our private header. The scanner generates code that uses ARRAY_LENGTH,
but we can just make it count the number elements and emit an integer
constant instead.
We don't have a use case for this and the actual semantics and
synchronization behavior of wl_egl_pixmap were never really well-defined.
It also doesn't provide the cross-process buffer sharing that make
window systems pixmaps useful in other window systems.
