Xwayland fatal error when Wayland output disappears

[Olivier Fourdan]

Hi,

On 23 November 2017 at 16:13, Olivier Fourdan <fourdan at gmail.com> wrote:

> FWIW, it seems we have that issue with more than just wl_output, in
> downstream bug 1516859 [1] this occurs with wl_seat on VT switch as well.
>
> That's pretty easy to reproduce, issue several VT switches back and forth
> (I use "chvt" from a remote connection) until the race occurs, here it
> doesn't take long.
>
> Cheers,
> Olivier
>
> [1]   https://bugzilla.redhat.com/show_bug.cgi?id=1516859
>


So, to be clear, the race here is between wl_seat capabilities and
wl_pointer.

On VT switch, the compositor notifies the clients of the changes in wl_seat
capabilities, Xwayland creates and releases the pointer based on these
capabilities, and when switching quickly between VTs, by the time the
get_pointer() is processed by the compositor, the pointer has been released
from a previous capability change.

For clarity, I added a trace in Xwayland's init_pointer() and
release_pointer(), the following in a excerpt of the logs at the time of
the issue:

 *** Xserver-Message *** release_pointer: release pointer

[1868330.603]  -> wl_pointer at 53.release()
[1868330.643]  -> zwp_relative_pointer_v1 at 54.destroy()

[1868330.683] wl_seat at 13.capabilities(2)
[1868330.687]  -> wl_seat at 13.get_keyboard(new id wl_keyboard at 55)
[1868330.704] wl_seat at 13.capabilities(3)

 *** Xserver-Message *** init_pointer: create pointer

[1868330.709]  -> wl_seat at 13.get_pointer(new id wl_pointer at 56)
[1868330.726]  -> zwp_relative_pointer_manager_v1 at 16.get_relative_pointer(new
id zwp_relative_pointer_v1 at 57, wl_pointer at 56)

[1868330.745] wl_seat at 13.capabilities(1)
[1868330.749]  -> wl_keyboard at 55.release()
[1868330.789] wl_seat at 13.capabilities(0)

 *** Xserver-Message *** release_pointer: release pointer

[1868330.794]  -> wl_pointer at 56.release()
[1868330.830]  -> zwp_relative_pointer_v1 at 57.destroy()

[1868381.340] wl_seat at 13.get_pointer(new id wl_pointer at 18)
[1868381.379]  -> wl_display at 1.error(wl_display at 1, 0, "invalid object 18")
[1868381.416] wl_display at 1.error(wl_display at 1, 0, "invalid object 18")

Unfortunately, I am not sure how to avoid this...

Cheers,
Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20171127/60d7ae18/attachment.html>