opening meld from gnome-terminal

[totaam]

Issue migrated from trac ticket # 2153

component: client | priority: major | resolution: fixed

2019-02-18 10:35:48: stdedos created the issue

---

Windows 10 Xpra-Python3-x86_64_Setup_2.5-[r21648](../commit/96bdb18ce0439957aea081222b529d218350c7fc) 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

[totaam]

2019-02-18 10:39:36: stdedos uploaded file xpra-meld-crash.zip (3.8 KiB)

[totaam]

2019-02-18 10:54:41: stdedos commented

---

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

[totaam]

2019-02-18 11:46:07: antoine changed owner from antoine to stdedos

[totaam]

2019-02-18 11:46:07: antoine commented

---

Please post the output of the OpenGL_check.exe tool.

[totaam]

2019-02-18 12:31:35: stdedos uploaded file xpra-2153_OpenGL_check.txt (5.1 KiB)

[totaam]

2019-02-18 16:10:16: antoine commented

---

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 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?

[totaam]

2019-02-18 19:05:12: stdedos commented

---

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

---

Replying to [comment:3 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](../commit/96bdb18ce0439957aea081222b529d218350c7fc)
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.

• = this is something that "routinely" happens for me, and maybe it's not to "recovering" the session. I suspect it might be related to OpenGL, but I have no hard evidence

[totaam]

2019-02-19 02:48:33: antoine commented

---

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

• xpra initialization error: display is not set! #2151: no, this one causes startup failures
• xpra client not timing out #2131 / Dead shadow session, but process is still alive #2099 unlikely, affects shadow?

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.

[totaam]

2019-02-19 08:26:22: stdedos commented

---

Replying to [comment:5 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 ...

• xpra initialization error: display is not set! #2151: no, this one causes startup failures
• xpra client not timing out #2131 / Dead shadow session, but process is still alive #2099 unlikely, affects shadow?

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?

[totaam]

2019-02-19 09:09:07: antoine commented

---

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.

[totaam]

2019-02-24 17:25:24: stdedos commented

---

Started with:
Xpra-Client-x86_64_2.5-[r21454](../commit/5562fb4144e749efb368ee3bf0c242bfb03675be)\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](../commit/5562fb4144e749efb368ee3bf0c242bfb03675be)\xpra_cmd attach ssh://user@ip/2 --opengl=no

2019-02-23 19:23:15,964 Xpra GTK2 client version 2.5-[r21454](../commit/5562fb4144e749efb368ee3bf0c242bfb03675be) 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](../commit/a052b144e8aca1f688c7376a455c0ce83097ea9b) 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](../commit/5562fb4144e749efb368ee3bf0c242bfb03675be)/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](../commit/5562fb4144e749efb368ee3bf0c242bfb03675be)/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](../commit/5562fb4144e749efb368ee3bf0c242bfb03675be)\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.

[totaam]

2019-02-24 17:25:45: stdedos uploaded file xpra-2153-py2Client.zip (6.5 KiB)

[totaam]

2019-02-25 06:57:57: antoine commented

---

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

[totaam]

2019-02-25 17:34:43: stdedos commented

---

Replying to [comment:9 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:

• I didn't know if −−start−on−last−client−exit was working (neither could I come up with a testing solution)
• Trying to run the command from an xpra start ssh:/// gnome-terminal locked "that screen" instead of :0. Setting DISPLAY didn't help either. Since I couldn't verify ![1], I didn't know if e.g. the command run, failed to run, executed a "side-effect" etc.

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)

[totaam]

2019-02-25 17:36:14: antoine commented

---

Thank you, I will update server/client as soon as betas roll out
Updated beta builds were posted earlier today.

[totaam]

2019-02-25 19:35:49: stdedos commented

---

Replying to [comment:11 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](../commit/6312de47e8ead6126f72bd5dab640a92546f7c72)*

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

[totaam]

2019-02-26 01:17:11: antoine commented

---

I haven't asked apt-get yet, but the only r218XX I see is the 21828
Ah, right.
Ubuntu Xenial builds had been broken since r21739 (cython minimum version requirements), r21879 fixes that.

[totaam]

2019-03-06 04:47:49: antoine commented

---

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?

[totaam]

2019-03-19 04:38:30: antoine commented

---

As per the documentation glTexImage2D: data may be a null pointer. In this case, texture memory is allocated to accommodate a texture of width width and height height. And 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.

[totaam]

2019-03-19 06:07:57: stdedos commented

---

Replying to [comment:15 Antoine Martin]:

As per the documentation glTexImage2D: data may be a null pointer. In this case, texture memory is allocated to accommodate a texture of width width and height height. And 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?

[totaam]

2019-03-19 06:24:45: antoine changed status from new to closed

[totaam]

2019-03-19 06:24:45: antoine set resolution to fixed

[totaam]

2019-03-19 06:24:45: antoine commented

---

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

[totaam]

2020-03-03 21:13:50: stdedos commented

---

meld seems to be working now (r25468):

"Xpra-Python3-x86_64_4.0-[r25468](../commit/0f1c09d46a951677f268fb0cb38863fbd42a6575)\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](../commit/0f1c09d46a951677f268fb0cb38863fbd42a6575) 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](../commit/86fdb78c7bf461e68008d62bac8a4bf54dd5f12c) 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