Bug 99296

Summary: assertion 's->auto_usbredir_reqs > 0' failed
Product: Spice Reporter: Victor Toso <bugzilla>
Component: spice-gtkAssignee: Jonathon Jongsma <jonathon>
Status: RESOLVED NOTOURBUG QA Contact:
Severity: normal    
Priority: medium CC: carlosg, jadahl
Version: unspecified   
Hardware: Other   
OS: All   
See Also: https://bugzilla.gnome.org/show_bug.cgi?id=780422
Whiteboard:
i915 platform: i915 features:

Description Victor Toso 2017-01-06 07:29:50 UTC
Seeing the message above with remote-viewer in Fedora 25 (spice-gtk 0.33) and also with upstream spicy (master is 66c705caca74f61ffce8637bee38b1e5e4909062)
Comment 1 Jonathon Jongsma 2017-02-09 22:45:00 UTC
It looks like it's caused by a change in Gtk+, and it only happens in the 'wayland' Gdk backend. As far as I can tell we're getting mismatched focus-in and focus-out events. For example, we'll get a single focus-in and then 2 focus-out events.

I bisected Gtk+ and it points to the following Gtk+ commit:

commit ceada4adc26868b894a0a450fe3ff80a4b4846ad
Author: Jonas Ådahl <jadahl@gmail.com>
Date:   Fri Jul 1 17:03:36 2016 +0800

    wayland: Port to xdg_shell unstable v6
    
    https://bugzilla.gnome.org/show_bug.cgi?id=769937


I tried a very simple gtk test case and couldn't immediately reproduce it. So there may be something we're doing which triggers this behavior.
Comment 2 Jonas Ådahl 2017-02-13 11:04:57 UTC
How did you test when bisecting? You won't be able to run GTK+ clients prior to that commit on current GNOME. You could however test on the most recent version of weston, which should support running GTK+ clients both before and after that commit.
Comment 3 Jonathon Jongsma 2017-02-13 18:03:34 UTC
(In reply to Jonas Ådahl from comment #2)
> How did you test when bisecting? You won't be able to run GTK+ clients prior
> to that commit on current GNOME. You could however test on the most recent
> version of weston, which should support running GTK+ clients both before and
> after that commit.

Hmm. Well, I simply built Gtk+ and installed it into a separate prefix and then ran the spice client with LD_PRELOAD pointing to the just-built gtk and gdk libraries. I'm building and running on my Fedora 25 laptop (Gnome 3.22.2). Are you saying that this shouldn't have worked?
Comment 4 Jonas Ådahl 2017-02-16 01:32:52 UTC
(In reply to Jonathon Jongsma from comment #3)
> (In reply to Jonas Ådahl from comment #2)
> > How did you test when bisecting? You won't be able to run GTK+ clients prior
> > to that commit on current GNOME. You could however test on the most recent
> > version of weston, which should support running GTK+ clients both before and
> > after that commit.
> 
> Hmm. Well, I simply built Gtk+ and installed it into a separate prefix and
> then ran the spice client with LD_PRELOAD pointing to the just-built gtk and
> gdk libraries. I'm building and running on my Fedora 25 laptop (Gnome
> 3.22.2). Are you saying that this shouldn't have worked?

I'm saying that a different backend will be used prior to that commit, if you test this under the Fedora 25 GNOME desktop. If you start "weston", and test from inside weston, you should be able test with the same GDK backend (wayland) further back in time.
Comment 5 Jonathon Jongsma 2017-03-16 21:56:16 UTC
(In reply to Jonas Ådahl from comment #4)
> (In reply to Jonathon Jongsma from comment #3)
> > (In reply to Jonas Ådahl from comment #2)
> > > How did you test when bisecting? You won't be able to run GTK+ clients prior
> > > to that commit on current GNOME. You could however test on the most recent
> > > version of weston, which should support running GTK+ clients both before and
> > > after that commit.
> > 
> > Hmm. Well, I simply built Gtk+ and installed it into a separate prefix and
> > then ran the spice client with LD_PRELOAD pointing to the just-built gtk and
> > gdk libraries. I'm building and running on my Fedora 25 laptop (Gnome
> > 3.22.2). Are you saying that this shouldn't have worked?
> 
> I'm saying that a different backend will be used prior to that commit, if
> you test this under the Fedora 25 GNOME desktop. If you start "weston", and
> test from inside weston, you should be able test with the same GDK backend
> (wayland) further back in time.


Hi Jonas,

Sorry for the delay, but I finally got around to bisecting gtk+ under weston as you suggested above. And I now get the following as the first bad commit:

commit de2268000d7e3eb5e84603810f9a6f971efb1072
Author: Carlos Garnacho <carlosg@gnome.org>
Date:   Wed Jun 24 17:48:18 2015 +0200

    wayland: Ensure device grabs generate crossing/focus events
    
    On X11 this is something the windowing system does for us, which the
    wayland backend should emulate, being grabs completely client-side.
    
    So, if the grab and current focus windows differ, make sure we emit
    focus/crossing events as it corresponds to the grab device.



I suspect that Gtk+ is not handling a corner case properly here, but I don't know this code well enough to determine whether that's true or not. Can you look into it a bit? Should I open a bug against Gtk+?
Comment 6 Jonas Ådahl 2017-03-17 02:41:13 UTC
(In reply to Jonathon Jongsma from comment #5)
> (In reply to Jonas Ådahl from comment #4)
> > (In reply to Jonathon Jongsma from comment #3)
> > > (In reply to Jonas Ådahl from comment #2)
> > > > How did you test when bisecting? You won't be able to run GTK+ clients prior
> > > > to that commit on current GNOME. You could however test on the most recent
> > > > version of weston, which should support running GTK+ clients both before and
> > > > after that commit.
> > > 
> > > Hmm. Well, I simply built Gtk+ and installed it into a separate prefix and
> > > then ran the spice client with LD_PRELOAD pointing to the just-built gtk and
> > > gdk libraries. I'm building and running on my Fedora 25 laptop (Gnome
> > > 3.22.2). Are you saying that this shouldn't have worked?
> > 
> > I'm saying that a different backend will be used prior to that commit, if
> > you test this under the Fedora 25 GNOME desktop. If you start "weston", and
> > test from inside weston, you should be able test with the same GDK backend
> > (wayland) further back in time.
> 
> 
> Hi Jonas,
> 
> Sorry for the delay, but I finally got around to bisecting gtk+ under weston
> as you suggested above. And I now get the following as the first bad commit:
> 
> commit de2268000d7e3eb5e84603810f9a6f971efb1072
> Author: Carlos Garnacho <carlosg@gnome.org>
> Date:   Wed Jun 24 17:48:18 2015 +0200
> 
>     wayland: Ensure device grabs generate crossing/focus events
>     
>     On X11 this is something the windowing system does for us, which the
>     wayland backend should emulate, being grabs completely client-side.
>     
>     So, if the grab and current focus windows differ, make sure we emit
>     focus/crossing events as it corresponds to the grab device.
> 
> 
> 
> I suspect that Gtk+ is not handling a corner case properly here, but I don't
> know this code well enough to determine whether that's true or not. Can you
> look into it a bit? Should I open a bug against Gtk+?

CC:ing Carlos, as he might have a better idea of how this could affect other things. Either way, opening a GTK+ bug might be a good idea.
Comment 7 Carlos Garnacho Parro 2017-03-18 17:07:36 UTC
Does a single grab op produce these 2 focus out events? As we're talking about focus events, I take it this is a keyboard, where is it focused before and after the grab? inside the same window, a different window from the same client...?

I agree this probably should be tracked in a gtk+ bug (a testcase would be great too), I guess it's most probably it producing the extra focus event, but I'm unclear how.
Comment 8 Jonathon Jongsma 2017-03-21 15:07:34 UTC
(In reply to Carlos Garnacho Parro from comment #7)
> Does a single grab op produce these 2 focus out events? As we're talking
> about focus events, I take it this is a keyboard, where is it focused before
> and after the grab? inside the same window, a different window from the same
> client...?
> 
> I agree this probably should be tracked in a gtk+ bug (a testcase would be
> great too), I guess it's most probably it producing the extra focus event,
> but I'm unclear how.

I haven't been able to produce a minimal test case so far. For what it's worth, if you have a fedora25 machine, it can be reproduced quite easily with the stock virt-viewer. Simply connect to a guest, then click outside of the virt-viewer window to release the grab, and you will see a warning printed to the terminal. I will try to open an upstream Gtk+ bug soon.
Comment 9 Carlos Garnacho Parro 2017-03-21 23:40:49 UTC
Thanks! I'll try to reproduce with those steps
Comment 10 Jonathon Jongsma 2017-03-22 21:18:15 UTC
I've opened a bug in gtk+: https://bugzilla.gnome.org/show_bug.cgi?id=780422

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.