Xpra attach crashes gnome-shell on Xwayland/gdm3 #3630
Comments
That sounds like a bug in your window manager.
Xpra does not use any JS code directly, or Clutter. This is the appindicator system tray replacement:
One should never need to restart the window manager, the display manager even less. |
Starting xpra with this option, can confirm there's no freezing on the window manager.
Or something is really wrong in the way xpra initializes itself, and perhaps there is a better way it can integrate with the tray that doesn't block other asynchronous tasks. When was the last time the Gdk code was updated? GTK3+ might have deprecated something, or there's a better way to interact with the tray. |
|
Given the information you've given, running with Freeze happens here, then after a few seconds. Noting that the timestamps suggest that xpra itself has not stopped continuing its progress, except for the last two lines where it gave up trying to set-up audio (not used on my end, so ignored). |
|
Also noting that rather that using GTK3's libappindicator, ubuntu "helpfully" provide their own fork, which is installed and used instead of the default appindicator library. |
I'm not seeing any problems running appindicator_tray.py directly. |
Even if that were the case, no window manager should ever hang by using one of its public APIs. That's a DoS and they need to fix it.
That's the point. This API should not block as it must be used from the UI thread.
They've deprecated and changed lots of things, multiple times, often without valid replacements. The freeze happens near:
Other things worth trying to narrow things down:
BTW, the issue description says
|
Of everything here, nothing makes a difference in behaviour. I did set As it seems that nothing else is happening at the same time, I guess I could try to localize what part of the appindicator code is disabled, see if it comes down to just one API call. Time willing of course. :-)
It's probably been about a decade since I read up anything about display servers, so I don't know whether Xorg vs. Xwayland is still a thing to be mindful of. |
Incidentally, I do have Xorg alongside Wayland still, switched over to Xorg and there's not even a stutter when running xpra attach. So this is specific to running the client on top of Wayland. |
totaam
added a commit
that referenced
this issue
Sep 30, 2022
|
@ibuclaw Does it hang "less" if you run with |
Yes, still getting a hang. So I've had a little time to prod around gtk_tray_menu_base.py, and it looks like there is a clear correlation between the number of items appened to the menu, and how sluggish the start-up seems to be. These submenu.append calls are the two biggest offenders. --- a/xpra/client/gtk_base/gtk_tray_menu_base.py
+++ b/xpra/client/gtk_base/gtk_tray_menu_base.py
@@ -1163,8 +1163,10 @@ class GTKTrayMenuBase(MenuHelper):
variant_submenu = Gtk.Menu()
variant.set_submenu(variant_submenu)
self.layout_submenu.append(variant)
+ log("%s - Default" % layout)
variant_submenu.append(kbitem("%s - Default" % layout, layout, None))
for v in variants:
+ log("%s - %s" % (layout, v))
variant_submenu.append(kbitem("%s - %s" % (layout, v), layout, v))
else:
#no variants:Dump generated from above patch |
|
Patch to skip generating menu items helps. Seems fine, as they will just be hidden anyway. --- a/xpra/client/gtk_base/gtk_tray_menu_base.py
+++ b/xpra/client/gtk_base/gtk_tray_menu_base.py
@@ -1124,6 +1124,7 @@ class GTKTrayMenuBase(MenuHelper):
log("make_layoutsmenuitem() layout=%s, layouts=%s, variant=%s, variants=%s",
layout, layouts, variant, variants)
full_layout_list = False
+ kh = self.client.keyboard_helper
if len(layouts)>1:
log("keyboard layouts: %s", ",".join(bytestostr(x) for x in layouts))
#log after removing dupes:
@@ -1147,7 +1148,7 @@ class GTKTrayMenuBase(MenuHelper):
self.layout_submenu.append(default)
for v in variants:
self.layout_submenu.append(kbitem("%s - %s" % (layout, v), layout, v))
- else:
+ elif not (kh.layout or kh.query_struct):
full_layout_list = True
from xpra.keyboard.layouts import X11_LAYOUTS
#show all options to choose from:
@@ -1169,7 +1170,6 @@ class GTKTrayMenuBase(MenuHelper):
else:
#no variants:
self.layout_submenu.append(kbitem(name, layout, None))
- kh = self.client.keyboard_helper
def set_layout_enabled(*args):
log(f"set_layout_enabled({args}) full_layout_list={full_layout_list}")
log(f"set_layout_enabled({args}) layout={kh.layout}, query-struct={kh.query_struct}")The fastest of course is just to remove everything. :-) |
|
So the thing to do now would be to attach and disconnect repeatedly, to see if gnome-shell still locks up on xpra attach. The current assumption now is that a huge (> 700 menu items) GTK tray, plus some other external event (GC?) causes the entire gnome WM to freeze indefinitely. |
But less than before, right?
These should be almost free, they are on X11.
Haha, yes. Turn off the computer and the bugs are all gone too. |
Not really, I can't see anything that would suggest it bloats the tray.
Right, the creation of the menu is free, but sending of this massive menu off to libappindicator causes it to freeze. This line right here is where we pass the point of no return. https://github.com/Xpra-org/xpra/blob/master/xpra/platform/xposix/appindicator_tray.py#L58-L59 Modifying --- a/xpra/platform/xposix/appindicator_tray.py
+++ b/xpra/platform/xposix/appindicator_tray.py
@@ -156,8 +156,8 @@ def main(): # pragma: no cover
sub = Gtk.MenuItem(label="Sub Menu Item 1")
subsubmenu = Gtk.Menu()
sub.set_submenu(subsubmenu)
- subsubmenu.append(Gtk.MenuItem(label="Sub Sub Menu Item 1"))
- subsubmenu.append(Gtk.MenuItem(label="Sub Sub Menu Item 2"))
+ for n in range(1, 1000):
+ subsubmenu.append(Gtk.MenuItem(label="Sub Sub Menu Item "+str(n)))
submenu.append(sub)
sub = Gtk.MenuItem(label="Sub Menu Item 2")
submenu.append(sub)This is a dump of the full menu (somewhat prettified). |
|
By the way, thanks a lot for the pointers. It's very much appreciated. :-) |
totaam
added a commit
that referenced
this issue
Oct 1, 2022
totaam
added a commit
that referenced
this issue
Oct 1, 2022
and add an env toggle to skip it if we want to
|
@ibuclaw is the latest change good enough to release 4.4?
The start menu is pretty big, it gets populated after the connection is established: xpra/xpra/client/gtk_base/gtk_tray_menu_base.py Line 1492 in 3f5ff9a |
Looks good, there's even some options to choose from now. |
Yes, I couldn't resist adding this trivial change: 3f5ff9a |
FAOD, I did a quick scan of this sub-menu, there are around ~70 start applications vs. ~700 keyboard layouts when I run xpra. That factor 10 difference makes the brief "freeze" seconds rather than maybe hundredths of milliseconds. I'll keep an eye on this anyway, let my client session run for a week or so to see if over time things really begin to slow down. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Over time during a mid-running desktop session (i.e: a week, including suspend/resume), after a few dozen xpra attach/disconnects, the start-up time for
xpra attachstarts to become sluggish, and can freeze the entire display manager for 60+ seconds before the remote window shows - unstucking the gnome-shell session. (Under "normal" operation, the entire display manager freezes for 1-3 seconds, which may itself be a bug, as Xpra must be doing something very wrong if any sort of freezing occurs at all just to load the initial window)At some point though, the gnome-shell session never recovers, with Xpra - and all other running X applications - frozen.
From journald
Plus some other variations of
The offending signal wasandThe offending callback wasmessage.On the console side from the xpra invocation
Where it promptly hangs - only killing gnome-shell, and restarting gdm3 can bring it back out of the sorry mess it's in.
To Reproduce
Steps to reproduce the behavior:
xpra start :100 --start="flatpak run org.mozilla.firefox"xpra attach ssh://ibuclaw@172.3.4.5/100System Information (please complete the following information):
Additional context
Attaching journald.log which captures moment from xpra invocation, to restarting gdm3.
The text was updated successfully, but these errors were encountered: