When closing client apps (e.g. weston-terminal, dnd, various efl apps, etc...) the following error message gets printed to console: "libwayland: error marshalling arguments for leave (signature uo): null value passed for arg 1" This also happens when activating/clicking on a context menu item in a weston demo client. The error does not appear to be fatal. wayland (master) heads/master-0-gbca4124 fontconfig (master) heads/master-0-gcd9b103 drm (master) heads/master-0-ga0178c0 mesa (master) heads/master-0-g6057d7b libxkbcommon (master) xkbcommon-0.3.1-0-g9f01bd1 pixman (master) heads/master-0-g279bdcd cairo (master) heads/master-0-gc51b850 weston (master) heads/master-0-g26ed73c wayland-fits (master) heads/master-0-g5f1a8cc First bad commit is: http://cgit.freedesktop.org/wayland/weston/commit/?id=26ed73cee858956f6af07c3e4bb49b5514f17b8b
The same error message can also be seen in the weston check serverlogs.
I think Jason Ekstrand's patch on the list might resolve this one: "[PATCH] Allow null surface arguments in wl_pointer.leave and wl_keyboard.leave" Would be worth checking.
(In reply to comment #2) > I think Jason Ekstrand's patch on the list might resolve this one: "[PATCH] > Allow null surface arguments in wl_pointer.leave and wl_keyboard.leave" > > Would be worth checking. Confirmed. Jason's patch (http://lists.freedesktop.org/archives/wayland-devel/2013-June/009920.html) fixes this.
commit 9dadfb53526bc97d62dc01c165e8b6f722f7ea5a Author: Kristian Høgsberg <krh@bitplanet.net> Date: Mon Jul 8 13:49:36 2013 -0400 compositor: Eliminate marshalling warning for leave events Don't NULL the resource pointer before calling weston_surface_destroy(). We use to have more of a distinction between compositor created surfaces and client surfaces, and weston_surface_destroy couldn't be used for client surfaces. Now it all goes through weston_surface_destroy() and we can remove the assert and the NULL-ing of resource, which caused the marshalling warning. diff --git a/src/compositor.c b/src/compositor.c index a02da8b..92d89a7 100644 --- a/src/compositor.c +++ b/src/compositor.c @@ -1002,9 +1002,6 @@ struct weston_frame_callback { WL_EXPORT void weston_surface_destroy(struct weston_surface *surface) { - /* Not a valid way to destroy a client surface */ - assert(surface->resource == NULL); - wl_signal_emit(&surface->destroy_signal, &surface->resource); struct weston_compositor *compositor = surface->compositor; @@ -1053,7 +1050,6 @@ destroy_surface(struct wl_resource *resource) { struct weston_surface *surface = wl_resource_get_user_data(resource); - surface->resource = NULL; weston_surface_destroy(surface); }
This issue was just reintroduced with: commit 0d379744d34e616fea840272deda6b7027f79f55 Author: Giulio Camuffo <giuliocamuffo@gmail.com> Date: Fri Nov 15 22:06:15 2013 +0100 compositor: set weston_surface:resource to NULL when destroyed with the previous patch the resource isn't used inside weston_surface_destroy() anymore (aside sending events unuseful for a closing client), so we can safely reset it. Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
*** Bug 72250 has been marked as a duplicate of this bug. ***
basically 0d379744d34e616fea840272deda6b7027f79f55 reverted the fix 9dadfb53526bc97d62dc01c165e8b6f722f7ea5a
This issue breaks EFL-Wayland (https://phab.enlightenment.org/T601). EFL-Wayland destroys it's underlying wl_surface when hiding or withdrawing windows and this issue causes Weston to disconnect the associated EFL client. In turn the EFL main loop exits prematurely.
Fixed again in: commit 65a07f8aef9538602792b33cb33fe856708173c0 Author: Giulio Camuffo <giuliocamuffo@gmail.com> Date: Fri Dec 6 12:46:27 2013 +0100 input: make sure the devices get the resource destruction signal The device may not have a resource for the client yet, but install the listeners nevertheless. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=65726
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.