xpra icon
Bug tracker and wiki

Opened 3 months ago

Closed 2 months ago

#2153 closed defect (fixed)

opening meld from gnome-terminal

Reported by: stdedos Owned by: stdedos
Priority: major Milestone: 2.5
Component: client Version: 2.4.x
Keywords: Cc:

Description

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

Attachments (3)

xpra-meld-crash.zip (3.8 KB) - added by stdedos 3 months ago.
xpra-2153_OpenGL_check.txt (5.1 KB) - added by stdedos 3 months ago.
xpra-2153-py2Client.zip (6.5 KB) - added by stdedos 3 months ago.

Download all attachments as: .zip

Change History (20)

Changed 3 months ago by stdedos

Attachment: xpra-meld-crash.zip added

comment:1 Changed 3 months ago by stdedos

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

Last edited 3 months ago by stdedos (previous) (diff)

comment:2 Changed 3 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

Please post the output of the OpenGL_check.exe tool.

Changed 3 months ago by stdedos

Attachment: xpra-2153_OpenGL_check.txt added

comment:3 Changed 3 months ago by 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?

comment:4 in reply to:  3 Changed 3 months ago by 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.

  • = 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
Last edited 3 months ago by stdedos (previous) (diff)

comment:5 Changed 3 months ago by 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 ...

  • #2151: no, this one causes startup failures
  • #2131 / #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.

comment:6 in reply to:  5 Changed 3 months ago by 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 ...

  • #2151: no, this one causes startup failures
  • #2131 / #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?

comment:7 Changed 3 months ago by 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.

comment:8 Changed 3 months ago by 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.

Changed 3 months ago by stdedos

Attachment: xpra-2153-py2Client.zip added

comment:9 Changed 3 months ago by 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.

comment:10 in reply to:  9 Changed 3 months ago by 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:

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

Last edited 3 months ago by Antoine Martin (previous) (diff)

comment:11 Changed 3 months ago by Antoine Martin

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

Updated beta builds were posted earlier today.

comment:12 in reply to:  11 Changed 3 months ago by 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

comment:13 Changed 3 months ago by 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.

comment:14 Changed 2 months ago by 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?

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

comment:15 Changed 2 months ago by 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.

comment:16 in reply to:  15 Changed 2 months ago by stdedos

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

comment:17 Changed 2 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.