Xpra: Ticket #2153: opening meld from gnome-terminal

Windows 10 Xpra-Python3-x86_64_Setup_2.5-r21648 to Ubuntu 16.04.5

"C:\Program Files\Xpra\xpra_cmd" start ssh://sntentos@172.16.57.121/  --start=gnome-terminal

and then, I tried to open meld from there.

The xpra connection "immediately closed" on the client; attached is the output from server and client



Mon, 18 Feb 2019 10:39:36 GMT - stdedos: attachment set


Mon, 18 Feb 2019 10:54:40 GMT - stdedos:

with --opengl=no application does start, but has other issues that force me to re-attach to make it working. (maybe clipboard related?)


Mon, 18 Feb 2019 11:46:06 GMT - Antoine Martin: owner changed

Please post the output of the OpenGL_check.exe tool.


Mon, 18 Feb 2019 12:31:34 GMT - stdedos: attachment set


Mon, 18 Feb 2019 16:10:16 GMT - Antoine Martin:

First the client side. From the opengl diagnostics, I see that you're using an Intel chipset, those are known to cause various problems, see wiki/ClientRendering/OpenGL.

I have never seen any drivers reporting the error that you are hitting:

  File "E:\Xpra\trunk\src/xpra/client/gl/gl_window_backing_base.py", line 443, in gl_init

This corresponded to:

glTexImage2D(target, 0, self.internal_format, w, h, 0, self.texture_pixel_format, GL_UNSIGNED_BYTE, None)

A workaround was easy enough to implement: r21687, and it shouldn't be too expensive to allocate and throw-away a few megabytes of empty memory - this is only used during initialization or window resizing. That said, it may or may not help.

FWIW: I tried removing a similar empty buffer initialization code in r21691 but that caused errors with the nvidia driver on win32 (and nowhere else!), so r21693 takes the same approach there.

There are new builds uploaded to the beta area.

FWIW: I'm doing the same thing from a windows-7 machine with an nvidia quadro card in it, also connecting to an ubuntu 16.04 system, and I'm not seeing any errors at all, with or without opengl enabled.

I think that these errors may follow window resizing, or window cleanup when the client terminates - possibly caused by a server crash (see below). So if the fixes above don't help, please post the -d geometry,opengl,metadata client log of a crash.

maybe clipboard related?

Have you tried disabling the clipboard?

It's also worth trying the python3 builds, just in case.


The server side is even more interesting:

2019-02-18 12:26:23,877 XShmWrapper.setup() shmget(PRIVATE, 18446744073701559216 bytes, 0x3ff) failed, bytes_per_line=131004, width=32751, height=32723
2019-02-18 12:26:23,877 Warning: disabling XShm support following irrecoverable error
Xpra: Fatal IO error 11 (Resource temporarily unavailable) on X server :1.

That looks like a hard X11 server crash. Was the vfb still running or also crashed? Can you recover the session by re-starting xpra with: xpra start --use-display :1?


Mon, 18 Feb 2019 19:05:12 GMT - stdedos:

Not sure if it's mentioned anywhere: "assigned" display is :1


Replying to Antoine Martin:

It's also worth trying the python3 builds, just in case.

Win10 already using Python3? Xpra-Python3-x86_64_Setup_2.5-r21648 If you mean the server AKA Ubuntu 16.04, I have no idea how to switch.

I have installed the xpra package, but there is no xpra3 package (there is python3-xpra, but no idea how to pull that instead of the py2)


That looks like a hard X11 server crash.

In my ears, it could be anything related to #2151, #2131, #2099 ... Luckily:

Was the vfb still running or also crashed?

No idea. Of the top of my head:

$ ps aux | grep vfb
sntentos  6500  0.0  0.2 373116 141884 ?       Ssl  12:06   0:13 Xvfb-for-Xpra-S6482 +extension GLX +extension Composite -screen 0 5760x2560x24+32 -dpi 96 -nolisten tcp -noreset -auth /home/sntentos/.Xauthority -displayfd 5
sntentos 17127  0.0  0.1 339888 109224 ?       Ssl  20:48   0:00 Xvfb-for-Xpra-:2 +extension GLX +extension Composite -screen 0 5760x2560x24+32 -dpi 96 -nolisten tcp -noreset -auth /home/sntentos/.Xauthority :2

Can you recover the session by re-starting xpra with: xpra start --use-display :1?

Session was recoverable. The image was not complete (a lot of black, in random regions), dragging it around was creating "image breaks/black-ness/almost-transparent regions"* - re-attaching fixed it. Holding on to the screen for diagnostics, if needed.


Tue, 19 Feb 2019 02:48:33 GMT - Antoine Martin:

Not sure if it's mentioned anywhere: "assigned" display is :1

AFAICT, not explicitly. For bug reports, it's easier if you specify the display yourself, then all the steps can be reproduce with a simple cut + paste. Also prevents confusion with multiple sessions / left-overs.

Win10 already using Python3?

Sorry, I had missed that. In this case, try python2 instead.

On ubuntu, you could install python3-xpra but this only supports servers with the 2.5 beta. And then you need to run xpra with: python3 /usr/bin/xpra ...

In my ears, it could be anything related to #2151, #2131, #2099 ...

Session was recoverable.

Was it recoverable by just re-attaching xpra or did you have to re-spin the xpra server?

The image was not complete (a lot of black, in random regions), dragging it around was creating "image breaks/black-ness/almost-transparent regions" - re-attaching fixed it. Holding on to the screen for diagnostics, if needed.

Maybe try to run a screen capture like scrot or xwd on it and attach it here? It would be interesting to see if xpra got messed up or if the vfb backing is also in a bit of a state.

I suspect it might be related to OpenGL, but I have no hard evidence

Sounds plausible, you may want to run with virtualgl, not just to get acceleration but also to use a different opengl backend.


Tue, 19 Feb 2019 08:26:21 GMT - stdedos:

Replying to Antoine Martin:

Not sure if it's mentioned anywhere: "assigned" display is :1

AFAICT, not explicitly. For bug reports, it's easier if you specify the display yourself, then all the steps can be reproduce with a simple cut + paste. Also prevents confusion with multiple sessions / left-overs.

I know; the thing is I use a prefab scripts to open things. The bad thing is, I have no idea how to write Windows Terminal scripts that have "some" interaction :/ I don't want to hit the same screen if it's borked in one way or another; I just want a new terminal.

Win10 already using Python3?

Sorry, I had missed that. In this case, try python2 instead.

Administrator operations are a tad more complicated on the laptop. Maybe I should just switch to the zip-clients and forget about the hassle. I'll try to replicate with a py2 build

On ubuntu, you could install python3-xpra but this only supports servers with the 2.5 beta. And then you need to run xpra with: python3 /usr/bin/xpra ...

I can try, but then - will the client operate "seamlessly", or would that orchestration require more?

In my ears, it could be anything related to #2151, #2131, #2099 ...

Well, I thought something more serious was happening on #2151 (that borked in some way or another X11), and then the "leftovers" were not handled correctly? idk...

Session was recoverable.

Was it recoverable by just re-attaching xpra or did you have to re-spin the xpra server?

Based on:

/run/user/1000/xpra$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
	UNKNOWN session at :1
	LIVE session at :20
/run/xpra:
	UNKNOWN session at :1
	LIVE session at :20
Re-probing unknown sessions in: /run/xpra, /run/user/1000/xpra
	UNKNOWN session at :1 (cleaned up)
	UNKNOWN session at :1 (cleaned up)

I'd say dead. Or idk. I couldn't do xpra attach :1 I just did xpra start --use-display :1 and I got all my windows etc back.

The image was not complete (a lot of black, in random regions), dragging it around was creating "image breaks/black-ness/almost-transparent regions" - re-attaching fixed it. Holding on to the screen for diagnostics, if needed.

Maybe try to run a screen capture like scrot or xwd on it and attach it here? It would be interesting to see if xpra got messed up or if the vfb backing is also in a bit of a state.

All this from "inside" the xpra, or simply a screen capture from the client machine? It seems xpra has "a very good idea" on what things look like. I just need to disconnect and re-attach to correctly display things.

I suspect it might be related to OpenGL, but I have no hard evidence

Sounds plausible, you may want to run with virtualgl, not just to get acceleration but also to use a different opengl backend.

What is the wrapper mentioned here:

You can also ensure that all your client applications are launched using vglrun by using the exec-wrapper option in your configuration file.

I cannot find it in https://xpra.org/manual.

Does that affect shadow or only --start[-child]= commands?


Tue, 19 Feb 2019 09:09:07 GMT - Antoine Martin:

And then you need to run xpra with: python3 /usr/bin/xpra ...

I can try, but then - will the client operate "seamlessly", or would that orchestration require more?

If both are installed, you must invoke xpra using python3 /usr/bin/xpra to use the python3 version. If only the python3 version is installed, it should just work automagically.

It would be interesting to see if xpra got messed up or if the vfb backing is also in a bit of a state.

All this from "inside" the xpra, or simply a screen capture from the client machine?

I meant directly on the server, without using xpra at all. ie: DISPLAY=:1 scrot

It seems xpra has "a very good idea" on what things look like. I just need to disconnect and re-attach to correctly display things.

Then the screenshot is probably not necessary. The vfb is fine, it's just xpra's connection to it that dropped, for whatever reason.

You can also ensure that all your client applications are launched using vglrun by using the exec-wrapper option in your configuration file.

I cannot find it in https://xpra.org/manual

oops, fixed: r21709 ie: I do xpra start --exec-wrapper="vglrun -d :1" --start=xterm

Does that affect shadow or only --start[-child]= commands?

Both, but since the display is already started with shadow, there is nothing to start.


Sun, 24 Feb 2019 17:25:24 GMT - stdedos:

Started with: Xpra-Client-x86_64_2.5-r21454\xpra_cmd start ssh://user@ip/2 --microphone=off --speaker=off --webcam=no --clipboard=no --start-new-commands=yes --start=gnome-terminal

[.....]

Screen crashed, recovered with xpra start --use-display :2, and then: Xpra-Client-x86_64_2.5-r21454\xpra_cmd attach ssh://user@ip/2 --opengl=no

2019-02-23 19:23:15,964 Xpra GTK2 client version 2.5-r21454 64-bit
2019-02-23 19:23:15,969  running on Microsoft Windows 10
2019-02-23 19:23:16,021 Warning: failed to import opencv:
2019-02-23 19:23:16,021  No module named cv2
2019-02-23 19:23:16,022  webcam forwarding is disabled
2019-02-23 19:23:16,507 GStreamer version 1.14.4 for Python 2.7.15 64-bit
2019-02-23 19:23:16,733  keyboard settings: layout=us
2019-02-23 19:23:16,736  desktop size is 1600x900 with 1 screen:
2019-02-23 19:23:16,737   Default (423x238 mm - DPI: 96x96) workarea: 1600x860
2019-02-23 19:23:16,738     DISPLAY1 (309x174 mm - DPI: 131x131)
2019-02-23 19:23:22,733 enabled remote logging
2019-02-23 19:23:22,737 Xpra GTK2 X11 server version 2.5-r21791 64-bit
2019-02-23 19:23:22,740  running on Linux Ubuntu 16.04 xenial
2019-02-23 19:23:22,782 Attached to 172.16.57.121:22 via ssh
2019-02-23 19:23:22,784  (press Control-C to detach)
_create_dc_and_bitmap: The parameter is incorrect.
2019-02-23 19:23:22,855 failed to instantiate <class 'xpra.client.gtk2.client_window.ClientWindow'>
Traceback (most recent call last):
  File "./xpra/client/mixins/window_manager.py", line 719, in make_new_window
  File "./xpra/client/client_window_base.py", line 65, in __init__
  File "./xpra/client/gtk_base/gtk_client_window_base.py", line 522, in setup_window
  File "./xpra/client/client_window_base.py", line 122, in setup_window
  File "./xpra/client/gtk_base/gtk_client_window_base.py", line 557, in new_backing
  File "./xpra/client/client_window_base.py", line 105, in new_backing
  File "./xpra/client/client_widget_base.py", line 51, in make_new_backing
  File "./xpra/client/gtk2/pixmap_backing.py", line 55, in init
  File "./xpra/client/gtk2/pixmap_backing.py", line 77, in do_init_new_backing_instance
RuntimeError: could not create GdkPixmap object
2019-02-23 19:23:22,870 no more options.. this window will not be shown, sorry
C:\Users\stavros.ntentos\Desktop\Xpra-Client-x86_64_2.5-r21454/lib/xpra/clipboard/clipboard_base.py:937: GtkWarning: ../../../gtk+-2.24.32/gdk/win32/gdkselection-win32.c:423: OpenClipboard failed: Access is denied.
2019-02-23 19:23:23,881 sound output using 'opus' audio codec
C:\Users\stavros.ntentos\Desktop\Xpra-Client-x86_64_2.5-r21454/lib/xpra/clipboard/clipboard_base.py:795: GtkWarning: gdk_property_change: assertion 'type != GDK_TARGET_STRING' failed
2019-02-23 19:29:00,835 sound output stopping

Initial meld window was not shown, restarting it, it worked nicely. Also --opengl=no, generally works okay.


I tried to run: Xpra-Client-x86_64_2.5-r21454\xpra_cmd start ssh://user@ip/5 --exec-wrapper="vglrun -d :5" --microphone=off --speaker=off --webcam=no --clipboard=no --start-new-commands=yes --start=gnome-terminal

but, it wasn't starting (check the attachment).

Maybe I'll need to do it directly from the server, I can try tomorrow.


Sun, 24 Feb 2019 17:25:45 GMT - stdedos: attachment set


Mon, 25 Feb 2019 06:57:57 GMT - Antoine Martin:

_create_dc_and_bitmap: The parameter is incorrect. (..) RuntimeError: could not create GdkPixmap object

That's a weird one. I have never seen this, but r21868 and r21873 should help if somehow the window ends up with completely messed up dimensions. You may also want to try the python3 builds, those use a different backend when opengl is disabled.

In your log I saw:

2019-02-23 19:29:00,825 Error spawning child '"DBUS_SESSION_BUS_ADDRESS=\"$(cut -f 2- -d= /run/user/1000/dbus-session)\" gnome-screensaver-command -l"':

Not sure what this is meant to do, why not just use start=gnome-screensaver-command -l? The server should retrieve the correct dbus session address for the session automatically, even when upgrading or using --use-display to recover a session.

And finally I think we have the real cause:

Warning: menu forwarding is disabled:
 cannot load dbus helper: org.freedesktop.DBus.Error.NoServer: Failed to connect to socket /tmp/dbus-xvD4Pz9X05: Connection refused

Then later:

2019-02-23 18:49:50,962 _read_initial_X11_properties()
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/x11/models/core.py", line 383, in _read_initial_X11_properties
    handler(self)
  File "/usr/lib/python2.7/dist-packages/xpra/x11/models/base.py", line 483, in _handle_gtk_app_menu_change
    query_actions(bus_name, app_path, app_actions_cb, app_actions_err)
NameError: global name 'query_actions' is not defined

I have no idea how it is possible for the code to end up trying to parse the menu stuff if it failed to load the menu forwarding components, but it did. So r21870 will use a different check so it never ends up calling the undefined function. r21871 will also trap all errors during the initial window setup.

I think that this could explain everything: it left the window in a half-initialized state, and its dimensions were completely random and invalid. The fix is server-side, but you can also try running the server with:

XPRA_MENU_FORWARDING=0 xpra start ...

This should make the problems go away.

In fact, this whole menu mess may be going away soon: #2163.


Mon, 25 Feb 2019 17:34:43 GMT - stdedos:

Replying to Antoine Martin:

_create_dc_and_bitmap: The parameter is incorrect. (..) RuntimeError: could not create GdkPixmap object

That's a weird one. I have never seen this, but r21868 and r21873 should help if somehow the window ends up with completely messed up dimensions. You may also want to try the python3 builds, those use a different backend when opengl is disabled.

Thank you, I will update server/client as soon as betas roll out

In your log I saw:

2019-02-23 19:29:00,825 Error spawning child '"DBUS_SESSION_BUS_ADDRESS=\"$(cut -f 2- -d= /run/user/1000/dbus-session)\" gnome-screensaver-command -l"':

Not sure what this is meant to do, why not just use start=gnome-screensaver-command -l? The server should retrieve the correct dbus session address for the session automatically, even when upgrading or using --use-display to recover a session.

I have had a two-pronged issue:

So r21870 will use a different check so it never ends up calling the undefined function. r21871 will also trap all errors during the initial window setup.

Thank you for the fix. I will test, however, when builds roll out. xpra is my windows window to the server, when server is unavailable. Since I cannot do that from the client, testing is (usually) hard. (and there are workarounds e.g. --opengl=no)


Mon, 25 Feb 2019 17:36:13 GMT - Antoine Martin:

Thank you, I will update server/client as soon as betas roll out

Updated beta builds were posted earlier today.


Mon, 25 Feb 2019 19:35:49 GMT - stdedos:

Replying to Antoine Martin:

Thank you, I will update server/client as soon as betas roll out

Updated beta builds were posted earlier today.

I don't see something here https://xpra.org/beta/xenial/main/binary-amd64/?P=*r218*

I haven't asked apt-get yet, but the only r218XX I see is the r21828


Tue, 26 Feb 2019 01:17:11 GMT - Antoine Martin:

I haven't asked apt-get yet, but the only r218XX I see is the r21828

Ah, right. Ubuntu Xenial builds had been broken since r21739 (cython minimum version requirements), r21879 fixes that.


Wed, 06 Mar 2019 04:47:48 GMT - Antoine Martin:

The opengl fix from comment:3 was causing a regression with normally well behaved drivers: #2194, so this has been reverted in r21981. This looks like a garbage collection issue, maybe we need to keep a reference to the empty buffer until we're certain pyopengl has uploaded it?


Tue, 19 Mar 2019 04:38:30 GMT - Antoine Martin:

As per the documentation glTexImage2d and Null data: GL still validates the pair of format and type but we do supply valid values for those: self.texture_pixel_format, GL_UNSIGNED_BYTE. So I think that the driver error is bogus and I'm not going to try to fix it.

Can I close this ticket? meld works for me.


Tue, 19 Mar 2019 06:07:57 GMT - stdedos:

Replying to Antoine Martin:

As per the documentation glTexImage2d and Null data: GL still validates the pair of format and type but we do supply valid values for those: self.texture_pixel_format, GL_UNSIGNED_BYTE. So I think that the driver error is bogus and I'm not going to try to fix it.

Can I close this ticket? meld works for me.

Well, if it is Intel shenanigans, then I guess I'll just stop using OpenGL on the Intel driver at all. You may go ahead and close.

Would using vlgrun have a chance to alleviate this problem?


Tue, 19 Mar 2019 06:24:45 GMT - Antoine Martin: status changed; resolution set

vglrun is used on the server side for sharing GPU acceleration with multiple contexts, it doesn't help with the client.


Tue, 03 Mar 2020 21:13:49 GMT - stdedos:

meld seems to be working now (r25468):

"Xpra-Python3-x86_64_4.0-r25468\xpra_cmd" start ssh://user@ip/20 --ssh="plink -ssh -agent" --microphone=off --speaker=off --webcam=no --pulseaudio=no --start-new-commands=yes --start=gnome-terminal
2020-03-03 23:08:18,528 Xpra GTK3 client version 4.0-r25468 64-bit
2020-03-03 23:08:18,530  running on Microsoft Windows 10
2020-03-03 23:08:19,429 GStreamer version 1.16.2 for Python 3.8.2 64-bit
2020-03-03 23:08:19,662 keyboard layout code 0x409
2020-03-03 23:08:19,663 identified as 'United States - English' : us
2020-03-03 23:08:19,794 OpenGL_accelerate module loaded
2020-03-03 23:08:19,833 Using accelerated ArrayDatatype
2020-03-03 23:08:20,474 Warning: vendor 'Intel' is greylisted,
2020-03-03 23:08:20,475  you may want to turn off OpenGL if you encounter bugs
2020-03-03 23:08:21,361 OpenGL enabled with Intel(R) HD Graphics 4000
2020-03-03 23:08:21,533  keyboard settings: layout=us
2020-03-03 23:08:21,537  desktop size is 1600x900 with 1 screen:
2020-03-03 23:08:21,538   Default (423x238 mm - DPI: 96x96) workarea: 1600x860
2020-03-03 23:08:21,539     (Standard monitor types) Generic PnP Monitor (309x174 mm - DPI: 131x131)
2020-03-03 23:08:31,358 enabled remote logging
2020-03-03 23:08:31,361 Xpra GTK3 X11 server version 3.0.6-r25174 64-bit
2020-03-03 23:08:31,362  running on Linux Ubuntu 16.04 xenial
(xpra_cmd:9920): Pango-WARNING **: 23:08:32.142: couldn't load font "Bitstream Vera Sans Not-Rotated 14.662109375", falling back to "Sans Not-Rotated 14.662109375", expect ugly output.
2020-03-03 23:08:54,176 UI thread is now blocked
2020-03-03 23:08:54,505 UI thread is running again, resuming
P

Sat, 23 Jan 2021 05:43:37 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2153