xpra icon
Bug tracker and wiki

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#1720 closed defect (fixed)

xpra attach hangs

Reported by: callegar Owned by: Antoine Martin
Priority: blocker Milestone: 2.3
Component: client Version: 2.2.x
Keywords: Cc:

Description (last modified by Antoine Martin)

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

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)

Attachments (1)

logxpra (516.5 KB) - added by callegar 2 years ago.
output of xpra -d all

Download all attachments as: .zip

Change History (18)

comment:1 Changed 2 years ago by Antoine Martin

Owner: changed from Antoine Martin to callegar

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

Ah, 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
Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 2 years ago by Antoine Martin

Description: modified (diff)

comment:3 Changed 2 years ago by callegar

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.

comment:4 Changed 2 years ago by callegar

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
Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:5 Changed 2 years ago by Antoine Martin

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")

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 2 years ago by callegar

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-r17607 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.

comment:7 Changed 2 years ago by callegar

xpra 2.2 seems to work with --no-tray

Changed 2 years ago by callegar

Attachment: logxpra added

output of xpra -d all

comment:8 Changed 2 years ago by callegar

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

comment:9 Changed 2 years ago by Antoine Martin

This is the downgrade closest to 2.2-r17607 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.

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:10 Changed 2 years ago by callegar

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.

comment:11 Changed 2 years ago by Antoine Martin

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.

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:12 Changed 2 years ago by Antoine Martin

Owner: changed from callegar to Antoine Martin
Status: newassigned

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

comment:13 Changed 2 years ago by Antoine Martin

Milestone: 2.3
Priority: criticalblocker

comment:14 Changed 2 years ago by callegar

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.

comment:15 Changed 2 years ago by callegar

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.

comment:16 Changed 2 years ago by callegar

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

comment:17 Changed 2 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

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 #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:

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

Last edited 2 years ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.