Re-attaching session damages server

[stdedos]

Creating the following session:

client r26623, server r26630

"Xpra-Python3_4.0.2-r26623\xpra_cmd" attach ssh://user@ip/20 --ssh="plink -ssh -agent" --modal-windows=no --title="@title@ on @@/@server-display@" --opengl=no --bandwidth-limit=6Mbps

2020-06-25 11:40:20,106 Xpra GTK3 client version 4.0.2-r26623 32-bit
2020-06-25 11:40:20,108  running on Microsoft Windows 10
2020-06-25 11:40:20,885 GStreamer version 1.16.2 for Python 3.8.3 32-bit
2020-06-25 11:40:21,322 keyboard layout code 0x409
2020-06-25 11:40:21,323 identified as 'United States - English' : us
2020-06-25 11:40:21,613  keyboard settings: layout=us
2020-06-25 11:40:21,616  desktop size is 4160x1440 with 1 screen:
2020-06-25 11:40:21,616   Default (1100x380 mm - DPI: 96x96) workarea: 4160x1400
2020-06-25 11:40:21,617     Generic PnP Monitor 1600x900 at 0x534 (309x174 mm - DPI: 131x131) workarea: 1600x860
2020-06-25 11:40:21,617     C32JG5x 2560x1440 at 1600x0 (697x392 mm - DPI: 93x93) workarea: 2560x1400
2020-06-25 11:40:31,411 enabled remote logging
2020-06-25 11:40:31,415 Xpra GTK3 X11 server version 3.0.10-r26630 64-bit
2020-06-25 11:40:31,415  running on Linux Ubuntu 16.04 xenial
2020-06-25 11:40:31,427 Attached to ip:22
2020-06-25 11:40:31,428  (press Control-C to detach)


(xpra_cmd:21588): Pango-WARNING **: 11:40:32.285: couldn't load font "Bitstream Vera Sans Not-Rotated 14.662109375", falling back to "Sans Not-Rotated 14.662109375", expect ugly output.
2020-06-25 11:40:32,832 sound output using 'opus' audio codec
2020-06-25 11:40:33,312 UI thread is now blocked
2020-06-25 11:40:33,329 UI thread is running again, resuming

And then stealing it from server's DISPLAY=:0, gives:

u@h [2020-06-25 16:55:23]:~$ xpra attach 2
2020-06-25 16:56:02,697 Xpra GTK3 X11 client version 3.0.10-r26630 64-bit
2020-06-25 16:56:02,756  running on Linux Ubuntu 16.04 xenial
2020-06-25 16:56:02,760  window manager is 'Compiz'
2020-06-25 16:56:02,844 No OpenGL_accelerate module loaded: No module named 'OpenGL_accelerate'
2020-06-25 16:56:03,077 OpenGL enabled with Quadro P400/PCIe/SSE2
2020-06-25 16:56:03,144  keyboard settings: rules=evdev, model=pc105, layout=us
2020-06-25 16:56:03,146  desktop size is 6400x1440 with 1 screen:
2020-06-25 16:56:03,147   :0.0 (1693x381 mm - DPI: 96x96) workarea: 6341x1416 at 59x24
2020-06-25 16:56:03,147     DP-0 2560x1440 (597x336 mm - DPI: 108x108)
2020-06-25 16:56:03,147     DP-2 1920x1080 at 2560x180 (527x296 mm - DPI: 92x92)
2020-06-25 16:56:03,147     DP-4 1920x1080 at 4480x180 (527x296 mm - DPI: 92x92)
2020-06-25 16:56:03,147  upscaled to 125%, virtual screen size: 5120x1152
2020-06-25 16:56:03,147   :0.0 (1693x381 mm - DPI: 76x76) workarea: 5073x1133 at 47x19
2020-06-25 16:56:03,147     DP-0 2048x1152 (597x336 mm - DPI: 87x87)
2020-06-25 16:56:03,147     DP-2 1536x864 at 2048x144 (527x296 mm - DPI: 74x74)
2020-06-25 16:56:03,147     DP-4 1536x864 at 3584x144 (527x296 mm - DPI: 74x74)
2020-06-25 16:56:03,169 Warning: invalid frame extents value '[0, 0, 0, 0, 0, 0, 28, 0]'
2020-06-25 16:56:03,169  this is probably a bug in 'Compiz'
2020-06-25 16:56:03,169  using '[0, 0, 28, 0]' instead
2020-06-25 16:56:03,281 enabled fast mmap transfers using 281MB shared memory area
2020-06-25 16:56:03,282 enabled remote logging
2020-06-25 16:56:03,282 Xpra GTK3 X11 server version 3.0.10-r26630 64-bit
2020-06-25 16:56:03,282  running on Linux Ubuntu 16.04 xenial
2020-06-25 16:56:03,283  no need for scaling with mmap
2020-06-25 16:56:03,283 setting scaling to 100%:
2020-06-25 16:56:03,285 sending updated screen size to server: 6400x1440 with 1 screens
2020-06-25 16:56:03,285   :0.0 (1693x381 mm - DPI: 96x96) workarea: 6341x1416 at 59x24
2020-06-25 16:56:03,285     DP-0 2560x1440 (597x336 mm - DPI: 108x108)
2020-06-25 16:56:03,285     DP-2 1920x1080 at 2560x180 (527x296 mm - DPI: 92x92)
2020-06-25 16:56:03,285     DP-4 1920x1080 at 4480x180 (527x296 mm - DPI: 92x92)
2020-06-25 16:56:03,289 Attached to socket:///run/user/1000/xpra/user-ix-main-pc-2
2020-06-25 16:56:03,289  (press Control-C to detach)

2020-06-25 16:56:03,375 Connection lost
/usr/lib/python3/dist-packages/xpra/client/gtk_base/gtk_client_base.py:150: Warning: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
  gtk_main()
2020-06-25 16:56:03,392 server does not support xi input devices
2020-06-25 16:56:03,393  server uses: xtest
u@h [2020-06-25 16:56:03]:~$

without attaching anything (a single gnome-terminal).

Server goes on a:

u@h [2020-06-25 16:54:08]:~$ xpra list
Found the following xpra sessions:
/run/user/1000/xpra:
	UNKNOWN session at :2
/run/xpra:
	UNKNOWN session at :2
Re-probing unknown sessions in: /run/xpra, /run/user/1000/xpra
^C
caught KeyboardInterrupt(), exiting

and gets rescued/attached succesfully afterwards

u@h [2020-06-25 16:55:15]:~$ xpra start --use-display=yes :2

Attaching server log (nothing suspicious in my eyes)

[Antoine Martin]

I'm not seeing this problem here.
It could be related to the randr resizing.
Does running the client with --desktop-scaling=no fix things?

[stdedos]

I am also getting this UUID displayed.

Bug or feature?

[stdedos]

Replying to Antoine Martin:

Does running the client with --desktop-scaling=no fix things?

Yes, it does.

55_server_x11.conf is amended with

xvfb = Xvfb +extension GLX +extension Composite -screen 0 7680x4320x24+32

Why does it need to scale? :/

[stdedos]

It seems that "stealing" has nothing to do with this - any attaching after the first "works" (or rather doesn't)

[Antoine Martin]

Why does it need to scale? :/

It's not clear to me if the -screen 0 7680x4320x24+32 is a new thing or not.
The default was 5760x2560, this has been bumped to 8192x4096 in 4.x

If the maximum size supported by the server is too small, the client will use desktop scaling to accommodate it.
With --desktop-scaling=auto (which is the default), the client will also enable scaling for high resolutions to save bandwidth.

---

Note that 3.0.12 has switched from Xdummy to Xvfb by default on Debian and Ubuntu. (ticket:1451#comment:14)

---

Tested with an Ubuntu Xenial 16.04 server running xpra 3.0.12 and an mswindows client running 4.1-r27631 with a triple monitor setup (via virtualbox).
I started an xterm and then a few more applications (Firefox, gedit, etc).
No amount of re-attaching, either from the Xenial system or from other systems (Fedora, etc) or back to the mswindows client caused any problems whatsoever with the server or with the application being forwarded.

[stdedos]

Hopefully I won't see it again either, since the next time I'll physically touch the computer, it will most likely be for a heavy 20.04.1 bump.