aa9536a992
We used to rely on the order in which the weston_compositor::destroy_signal callbacks happened, to not access freed memory. Don't know when, but this broke at least with ivi-shell, which caused crashes in random places on compositor shutdown. Valgrind found the following: Invalid write of size 8 at 0xC2EDC69: unbind_input_panel (input-panel-ivi.c:340) by 0x4E3B6BB: destroy_resource (wayland-server.c:537) by 0x4E3E085: for_each_helper.isra.0 (wayland-util.c:359) by 0x4E3E60D: wl_map_for_each (wayland-util.c:365) by 0x4E3BEC7: wl_client_destroy (wayland-server.c:675) by 0x4182F2: text_backend_notifier_destroy (text-backend.c:1047) by 0x4084FB: wl_signal_emit (wayland-server-core.h:264) by 0x4084FB: main (compositor.c:5465) Address 0x67ea360 is 208 bytes inside a block of size 232 free'd at 0x4C2A6BC: free (vg_replace_malloc.c:473) by 0x4084FB: wl_signal_emit (wayland-server-core.h:264) by 0x4084FB: main (compositor.c:5465) Invalid write of size 8 at 0x4E3E0D7: wl_list_remove (wayland-util.c:57) by 0xC2EDEE9: destroy_input_panel_surface (input-panel-ivi.c:191) by 0x4E3B6BB: destroy_resource (wayland-server.c:537) by 0x4E3BC7B: wl_resource_destroy (wayland-server.c:550) by 0x40DB8B: wl_signal_emit (wayland-server-core.h:264) by 0x40DB8B: weston_surface_destroy (compositor.c:1883) by 0x40DB8B: weston_surface_destroy (compositor.c:1873) by 0x4E3B6BB: destroy_resource (wayland-server.c:537) by 0x4E3E085: for_each_helper.isra.0 (wayland-util.c:359) by 0x4E3E60D: wl_map_for_each (wayland-util.c:365) by 0x4E3BEC7: wl_client_destroy (wayland-server.c:675) by 0x4182F2: text_backend_notifier_destroy (text-backend.c:1047) by 0x4084FB: wl_signal_emit (wayland-server-core.h:264) by 0x4084FB: main (compositor.c:5465) Address 0x67ea370 is 224 bytes inside a block of size 232 free'd at 0x4C2A6BC: free (vg_replace_malloc.c:473) by 0x4084FB: wl_signal_emit (wayland-server-core.h:264) by 0x4084FB: main (compositor.c:5465) Invalid write of size 8 at 0x4E3E0E7: wl_list_remove (wayland-util.c:58) by 0xC2EDEE9: destroy_input_panel_surface (input-panel-ivi.c:191) by 0x4E3B6BB: destroy_resource (wayland-server.c:537) by 0x4E3BC7B: wl_resource_destroy (wayland-server.c:550) by 0x40DB8B: wl_signal_emit (wayland-server-core.h:264) by 0x40DB8B: weston_surface_destroy (compositor.c:1883) by 0x40DB8B: weston_surface_destroy (compositor.c:1873) by 0x4E3B6BB: destroy_resource (wayland-server.c:537) by 0x4E3E085: for_each_helper.isra.0 (wayland-util.c:359) by 0x4E3E60D: wl_map_for_each (wayland-util.c:365) by 0x4E3BEC7: wl_client_destroy (wayland-server.c:675) by 0x4182F2: text_backend_notifier_destroy (text-backend.c:1047) by 0x4084FB: wl_signal_emit (wayland-server-core.h:264) by 0x4084FB: main (compositor.c:5465) Address 0x67ea368 is 216 bytes inside a block of size 232 free'd at 0x4C2A6BC: free (vg_replace_malloc.c:473) by 0x4084FB: wl_signal_emit (wayland-server-core.h:264) by 0x4084FB: main (compositor.c:5465) Looking at the first of these, unbind_input_panel() gets called when the text-backend destroys its helper client which has bound to input_panel interface. This happens after the shell's destroy_signal callback has been called, so the shell has already been freed. The other two errors come from wl_list_remove(&input_panel_surface->link); which has gone stale when the shell was destroyed (shell->input_panel.surfaces list). Rather than creating even more destroy listeners and hooking them up in spaghetti, modify text-backend to not hook up to the compositor destroy signal. Instead, make it the text_backend_init() callers' responsibility to also call text_backend_destroy() appropriately, before the shell goes away. This fixed all the above Valgrind errors, and avoid a crash with ivi-shell when exiting Weston. Also using desktop-shell exhibited similar Valgrind errors which are fixed by this patch, but those didn't happen to cause any crashes AFAIK. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Reviewed-By: Derek Foreman <derekf@osg.samsung.com> |
||
---|---|---|
.. | ||
.gitignore | ||
hmi-controller.c | ||
input-panel-ivi.c | ||
ivi-layout-export.h | ||
ivi-layout-private.h | ||
ivi-layout-transition.c | ||
ivi-layout.c | ||
ivi-shell.c | ||
ivi-shell.h | ||
README | ||
weston.ini.in |
In-vehicle infotainment (information and entertainment) graphical environment support modules for Weston IVI-shell is an alternative shell for Weston, a Wayland display server. Window management and application interaction with the display server are very different to that of a normal desktop, which is why this is a separate shell and not an extension to the desktop-shell suite with xdg_shell. As such, applications need to be specifically written to use IVI-shell. IVI-shell contains two main features: - Common layout library for surface, which allow ivi-shell developer to develop own shell, linking Common layout library. For the time being, the library refers Genivi ilm interface. http://projects.genivi.org/wayland-ivi-extension/ - Extension protocol; ivi-application to tie wl_surface and a given ID. With this ID, shell can identify which wl_surface is drawn by which application. In in-vehicle infortainment system, a shell has to update a property of a wl_surface. E.g. there may be a use case when vehicle starts to move, the wl_surface drawn by Car navigation is expected to move top of surfaces. The actual software components delivered with Weston are: - ivi-application.xml: Wayland protocol extension for IVI-applications; the public shell protocol (the same concept as xdg_shell). Implemented by ivi-shell.so. - ivi-shell.so: A Weston shell module that implements ivi-application.xml interfaces. Loads ivi-layout.so. - ivi-layout.so: Implements the IVI window management concepts: Screen, Layer, Surface, groups of Layers, groups of Surfaces, see: http://projects.genivi.org/ivi-layer-management/node/13 Offers a stable API for writing IVI-controller modules like hmi-controller.so against the IVI concepts. In other words, it offers an API to write IVI window manager modules. - hmi-controller.so: A sample implementation of an IVI-controller module, usually replaced by IVI system vendors. Uses ivi-layout.so to perform essentially window manager tasks. This implementation keeps all window management inside the module, while IVI-systems may use another module that exposes all window management via Wayland or other protocol for an external process to control: http://git.projects.genivi.org/?p=wayland-ivi-extension.git;a=summary - ivi-hmi-controller.xml: Wayland protocol extension for IVI display control; the private shell protocol for weston-ivi-shell-user-interface client (the same concept as desktop-shell.xml). Implemented by hmi-controller.so, and usually replaced by IVI system vendors. - weston-ivi-shell-user-interface: A sample implementation of an IVI shell helper client, usually replaced by IVI system vendors. A helper client for basic display content, similar to weston-desktop-shell. How to compile: same as weston. To disable, use option: --disable-ivi-shell for configure. How to configure weston.ini: reference ini file will be generated in <build_dir>/ivi-shell. How to run: same as weston. exec weston. How to use UI: http://lists.freedesktop.org/archives/wayland-devel/attachments/20140625/abbfc064/attachment-0001.png