xpra attach hangs

[totaam]

Issue migrated from trac ticket # 1720

component: client | priority: blocker | resolution: fixed

2017-12-12 22:40:02: callegar created the issue

---

Seen on Kubuntu 17.10, Intel graphics, using latest xpra deb file, namely 2.2-17607.

Executing xpra as a client as in

xpra attach :102

causes xpra to:

1. Briefly show its icon in the system tray
2. Have the system tray icon disappear
3. Hang (application does not react to ctrl-C and must be killed with kill -9)

No window from the server is shown.

Issue is totally repeatable on this machine. Strangely, I do not see it on another one with a very similar configuration but nvidia graphics. Trying multiple times, in some rare occasion some output is provided, such as

[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
python: ../../src/xcb_io.c:165: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
Aborted (core dumped)

[totaam]

2017-12-13 03:45:43: antoine changed owner from antoine to callegar

[totaam]

2017-12-13 03:45:43: antoine commented

---

Seen on Kubuntu 17.10, Intel graphics, using latest xpra deb file, namely 2.2-17607.
Ah, [/wiki/ClientRendering/OpenGL#IntelDriverIssues Intel Driver Issues]... We meet again.

See: #1233: 'whitelist some more intel chipsets?' (#1687)

The opengl code tries hard to avoid crashing, doing an initial test rendering before actually enabling the chipset... but if even the test rendering code crashes, there's not much we can do.

Please try:

• using the new --opengl=native command line option
• disabling opengl, and if that does not help, try disabling more things (clipboard, etc)
• posting the output of the gl_check.py tool: we may need to remove this particular chipset from the whitelist
• posting the end of the "-d opengl" client output, or even "-d all" if the problem is not opengl related

[totaam]

2017-12-13 03:45:56: antoine edited the issue description

[totaam]

2017-12-13 08:34:17: callegar commented

---

Some additional notes:

• historically Xpra has always worked with opengl on this machine with no issue.
• this is a haswell mobile chipset
• no --opengl= command seems to fix the issue
• running xpra with LIBGL_ALWAYS_SOFTWARE=1 which switches to software rendering effectively disabling the intel opengl causes xpra to detect the software rendering and indicate that it is blacklisted, but then one gets into the same issue. So the bug does not seem to be tied to the intel opengl implementation.

[totaam]

2017-12-13 08:40:15: callegar commented

---

Disabling the clipboard also makes no difference.

In one occasion, I managed to get another error:

/usr/lib/python2.7/dist-packages/xpra/gtk_common/gtk_util.py:493: GtkWarning: _gtk_container_dequeue_resize_handler: assertion 'GTK_CONTAINER_RESIZE_PENDING (container)' failed

[totaam]

2017-12-13 09:09:09: antoine commented

---

Can you run with "-d all" and post the end of the output?

And maybe also try with "--no-tray"? (and any other "--no-xyz")

[totaam]

2017-12-13 09:34:54: callegar commented

---

Downgrading to xpra 2.1.3-r17247 provides a working xpra client. Hence, apparently there is a regression in xpra.

This is the downgrade closest to 2.2-17607 for which I could find a deb.

As soon as I have no need to use xpra, I'll try switching back to 2.2 and saving the -d all output (which I expect to be rather long). I'll do the other --no-xxx tests too.

[totaam]

2017-12-13 09:50:21: callegar commented

---

xpra 2.2 seems to work with --no-tray

[totaam]

2017-12-13 09:51:02: callegar uploaded file logxpra (516.5 KiB)

output of xpra -d all

[totaam]

2017-12-13 09:53:28: callegar commented

---

Another issue seems to be the inability to use python-lz4, but this is probably unrelated.

[totaam]

2017-12-13 10:04:28: antoine commented

---

This is the downgrade closest to 2.2-17607 for which I could find a deb.
There are many more here: [http://xpra.org/beta]

xpra 2.2 seems to work with --no-tray
There must be something fishy going on with KDE, I'll try to find the time to install it.
There were no changes to the tray code in 2.2, so the bug is likely elsewhere and just happens to trigger here.

Another issue seems to be the inability to use python-lz4, but this is probably unrelated.
Good catch, fixed: r17610.

[totaam]

2017-12-13 10:22:38: callegar commented

---

There are many more here: ​http://xpra.org/beta

Thanks, I was looking only at what my package manager and package cache had on store. I'll now try more version to see if this can help bisecting.

There must be something fishy going on with KDE, I'll try to find the time to install it.

Fishy indeed, as I see it on a KDE machine and not on the other one that should have a largely similar setup.

[totaam]

2017-12-13 10:39:40: antoine commented

---

I'll now try more version to see if this can help bisecting.
Great. Thanks!

FYI: the updated python-lz4 packages have been added to the repository, apt-get update && apt-get dist-upgrade should be all you need to enable lz4 again. Tested on Ubuntu 17.10.

[totaam]

2017-12-13 10:44:33: antoine changed status from new to assigned

[totaam]

2017-12-13 10:44:33: antoine changed owner from callegar to antoine

[totaam]

2017-12-13 10:44:33: antoine commented

---

I can reproduce it under KDE only, so I should be able to fix it.

[totaam]

2017-12-13 10:44:47: antoine changed priority from critical to blocker

[totaam]

2017-12-15 11:53:29: callegar commented

---

Did some testing with the versions at http://xpra.org/beta available for ubuntu artful.

System tray support seems to break between 2.2-20171124r17497-1 and 2.2-20171126r17521-1. In the latter the tray icon appears and suddendly disappears. One also gets an error message about jpeg2k not being available.

However, in 2.2-20171126r17521-1, despite the tray issue there is no hang. The application can display the remote windows and exits properly with CTRL-C. So there must be something else too happening later on.

[totaam]

2017-12-15 12:04:42: callegar commented

---

Weird enough, while the disappearance of the tray entry is totally repeatable, looks like the hang is not. Today also the latest version of the xpra deb seems not to lock up in most occasions.

[totaam]

2017-12-15 14:10:06: callegar commented

---

Applied your latest patchsets. They fix the issue for me. Thanks for the very prompt action.

[totaam]

2017-12-15 14:34:03: antoine changed status from assigned to closed

[totaam]

2017-12-15 14:34:03: antoine set resolution to fixed

[totaam]

2017-12-15 14:34:03: antoine commented

---

This deserves a recap, or a rant, depending on how you look at it.

The system-tray under X11 is a complete train-wreck thanks to the misery inflected by KDE, Gnome and Ubuntu's appindicator. Each time, the senseless breakage they introduce is presented as some sort of improvement (if you force yourself to follow their convoluted reasoning). This is often using "consistency" as some sort of justification, which is baffling to anyone who deals with stable apis, the only thing that is consistent is the mess this constant breakage causes.

In comparison, the MS Windows API (Shell_NotifyIcon) is largely unchanged since Windows 2000 (and maybe even earlier?), and the updates are backwards compatible.

The systemtray-spec dates back to 2002 and although it isn't perfect, it uses well understood mechanisms (windows and selections).

So then we had Ubuntu's appindicator which broke everything and did so with an absolutely terrible API (see #406).
Gnome decided to not be left behind and create its own mess: hiding the systray in a place where noone could ever find it, then recently they decided to remove it altogether since noone uses it. (genius!)
Each version of KDE seems to have done things differently: Where are my systray icons?, introducing new apis.

---

KDE seems to be injecting its system tray API into GTK apps, and that's buggy as hell: I've seen their tray proxy process crash a number of times (and it doesn't come back, you have to reboot or logout and log back in - at least when it's crashed, we can launch xpra without problems!) and when it doesn't crash, the client tray API ends up deadlocked waiting for an X11 xcb reply that never comes. (we don't use xcb!)

The fixes I have come up with are:

• r17658: just wait a little while longer before calling the systray setup code. (maybe gnome shell uses the wrong window icon #1350 causes a SIGHUP?)
• r17662: keep track of the tray object
  Either one works.

In the meantime, you could use have used "--delay-tray" (but that was broken)..

---

Not the first KDE systray bug either, here are a bunch of systray related tickets:

• KDE - System Tray Icon is tiny #1146 "KDE - System Tray Icon is tiny"
• KDE system tray support #1016 "KDE system tray support" (requires GTK3: python3 #1568)
• tray icon breaks xpra attach on gnome 3.12 #681 "tray icon breaks xpra attach on gnome 3.12" - also fixed by "--delay-tray"
• workarounds for crippled desktop environments without a system tray (ie: gnome3) #476 "workarounds for crippled desktop environments without a system tray (ie: gnome3)"
• better native tray support for *nix #405 "better native tray support for *nix" - this would bypass the KDE injection, not necessarily a good thing unfortunatley
• fix gtk-osx to expose the system tray location #404 "fix gtk-osx to expose the system tray location" (macos)
• tray icon and menu icons are blank #43 "tray icon and menu icons are blank" (ubuntu unity)
• Xpra systray icons have black background. #1466 "Xpra systray icons have black background."

---

System tray support seems to break between 2.2-20171124r17497-1 and 2.2-20171126r17521-1.
In the latter the tray icon appears and suddendly disappears.
Thanks, that helps as my reproduction steps required re-setting the virtualbox image after every debugging attempt.
The only changeset that looks relevant here is r17512. It may explain the icon going missing, somehow, but not the crash.

One also gets an error message about jpeg2k not being available.
That has been silenced since, Ubuntu doesn't ship jpeg2k support in python-pillow. (see #618)

Since you reported that the fixes work, I am closing this ticket as "fixed".