There seems to be a race between a client disconnecting and the text protocol attempting to post an event to the dying client resource via wl_text_input_send_language(...). Various backtraces indicate that the resource is not always completely destructed before it reaches wl_resource_post_event(...), but ultimately results in a segmentation fault. See attached backtraces for more evidence of this issue. wayland (master) heads/master-0-g9a5ed78 drm (master) heads/master-0-gb6da447 mesa (master) heads/master-0-ga1b6e69 libva (master) heads/master-0-g73a11b3 intel-driver (master) heads/master-0-gd22d367 weston (master) heads/master-0-g4a4704a The only existing test case, so far, that reproduces this issue is the efl/shm/EntryCutTest in wayland-fits. Nonetheless, this appears to be a core issue unrelated to efl.
Created attachment 86017 [details] Resource is null
Created attachment 86018 [details] Resource interface events access violation
Created attachment 86019 [details] resource interface event signature is null
I can't seem to reproduce this one anymore with wayland/weston > 1.3 and latest master components: wayland (master) heads/master-0-g05f95c8 drm (master) heads/master-0-g1a84eea mesa (master) heads/master-0-g19c2f40 libva (master) heads/master-0-g73a11b3 intel-driver (master) heads/master-0-g46c4901 weston (master) heads/master-0-gf707e81 efl (master) heads/master-0-g90bbc21 elementary (master) heads/master-0-g4832558 wfits (master) heads/master-0-gbb9959e ...and I was unsuccessful in identifying which change could have fixed it :-/
Ok, I'm seeing this one again... wayland (master) heads/master-0-g5a019e3 drm (master) heads/master-0-gc3d9689 mesa (master) heads/master-0-gdecf070 libva (master) heads/master-0-g73a11b3 intel-driver (master) heads/master-0-g4a0f76c weston (master) heads/master-0-gda704d9 wfits (master) heads/master-0-g887e47f
commit c180977e7cfd36eb8286186ca9432b1d4cfef864 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Mon Jan 13 15:06:10 2014 -0800 text: Set context->model to NULL when we deactivate text input There's a small window between the input method (eg the on-sreen keyboard) receiving the deactivate and destroying the context, where the keyboard may send requests, which we forward to the destroyed input method. Fix this by setting the contexts model to NULL right away and then avoid sending events if context->model is NULL. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=69490
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.