Xpra: Ticket #2316: Trackbacks on bytestreams.py when HTML5 Client tries to reconnect

Happens regularly on Initial Connection with an HTML 5 Client. Once connected happens occasionally on launching of a new application, reconnection of session or disconnect

version - xpra v3.0-r22786

2019-06-04 12:04:05,994 untilConcludes(<bound method SocketConnection.is_active of tcp socket: 10.0.3.42:12000 <- 10.0.4.36:49783>, <bound method SocketConnection.can_retry of tcp socket: 10.0.3.42:12000 <- 10.0.4.36:49783>, <built-in method recv of _socket.socket object at 0x7f889fbdbc00>, (65536,), {}) timed out, retry=socket.timeout
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/bytestreams.py", line 116, in untilConcludes
    return f(*a, **kw)
timeout: timed out


Wed, 05 Jun 2019 02:54:21 GMT - Antoine Martin: status changed; resolution set

I think those are likely to be caused by #2315.

Feel free to re-open if you can reproduce with r22852 or later.


Tue, 11 Jun 2019 22:26:35 GMT - zaveri: status changed; resolution deleted

I am still seeing this on initial connection with xpra v3.0-r22875

2019-06-11 15:16:49,777 New tcp connection received from 10.0.4.71:59728 on 0.0.0.0:15000
2019-06-11 15:16:49,777 make_protocol(tcp, tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728, <function ServerCore.make_protocol.<locals>.xpra_protocol_class at 0x7f6fbe260f28>)
2019-06-11 15:16:49,777 io_thread_loop(read, <bound method Protocol._read of Protocol(tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728)>) loop starting
2019-06-11 15:16:49,878 untilConcludes(<bound method Connection.is_active of tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728>, <bound method Connection.can_retry of tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728>, <built-in method recv of socket object at 0x7f6fbe51c4c8>, (65536,), {}) timed out, retry=socket.timeout
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 116, in untilConcludes
    return f(*a, **kw)
socket.timeout: timed out
2019-06-11 15:16:49,978 untilConcludes(<bound method Connection.is_active of tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728>, <bound method Connection.can_retry of tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728>, <built-in method recv of socket object at 0x7f6fbe51c4c8>, (65536,), {}) timed out, retry=socket.timeout
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 116, in untilConcludes
    return f(*a, **kw)
socket.timeout: timed out
2019-06-11 15:16:50,078 untilConcludes(<bound method Connection.is_active of tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728>, <bound method Connection.can_retry of tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728>, <built-in method recv of socket object at 0x7f6fbe51c4c8>, (65536,), {}) timed out, retry=socket.timeout
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 116, in untilConcludes
    return f(*a, **kw)
socket.timeout: timed out

But I also saw the below traceback after A while

Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 116, in untilConcludes
    return f(*a, **kw)
OSError: [Errno 9] Bad file descriptor
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/protocol.py", line 643, in _io_thread_loop
    while not self._closed and callback():
  File "/usr/lib64/python3.7/site-packages/xpra/net/protocol.py", line 722, in _read
    buf = self._conn.read(self.read_buffer_size)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 327, in read
    return self._read(self._socket.recv, n)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 197, in _read
    r = self.untilConcludes(*args)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 182, in untilConcludes
    return untilConcludes(self.is_active, self.can_retry, *args)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 118, in untilConcludes
    retry = can_retry_cb(e)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 179, in can_retry
    return can_retry(e)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 106, in can_retry
    raise ConnectionClosedException(e)
xpra.net.common.ConnectionClosedException: [Errno 9] Bad file descriptor
2019-06-11 15:16:51,728 connection lost: invalid packet format, HTTP GET request
2019-06-11 15:16:51,728 Protocol.close() closed=True, connection=None

Note - once you start the xpra server, connect immediately via the HTML 5 client.


Wed, 12 Jun 2019 03:20:07 GMT - Antoine Martin: owner, status changed

Note - once you start the xpra server, connect immediately via the HTML 5 client.

I do this hundreds of times a day..

There are a lot of details missing, please see wiki/ReportingBugs. In particular: full command lines used, type of network connection, etc. Can you reproduce with older versions? (ie: 2.4.x in particular? anything before #2121) Can you reproduce with the regular python client? Is this running on a virtual machine? What kind? What host OS? What (paravirtualized?) network drivers? Please include the server's -d network debug output of a single failed connection attempt. (from New tcp connection received to Disconnecting client)

The socket.timeout is harmless and should not be visible without enabling debug logging. The ConnectionClosedException is the result of a closed connection and is not in itself a bug. This looks directly related to #2315. It might be useful to have a tcpdump trace of those connection failures.


Thu, 13 Jun 2019 23:43:25 GMT - zaveri:

We did another repro with the following xpra version-v3.0-r22922.

Using a Fed 30 VM, winswitch beta repo launch the server with the below command.

xpra --no-daemon --bind-tcp=0.0.0.0:14000 --start=xterm start :14 --sharing=yes -d network

The Server starts up, and when we see the 'xpra is ready' output from the server output, we then use Chrome 74 on a Windows 7 machine to connect to http://IP:14000.

From the point of XPRA is ready until the first traceback, here are the logs from the server.

2019-06-13 10:54:18,647 xpra is ready.
2019-06-13 10:54:25,141 printer forwarding enabled using postscript and pdf
2019-06-13 10:54:25,149 reply_handler()
2019-06-13 10:54:25,149 update_txt({'display': ':12', 'username': 'maint', ', 'name': 'xterm', 'clients': 0}) done
2019-06-13 10:54:25,151 reply_handler()
2019-06-13 10:54:25,151 update_txt({'display': ':12', 'username': 'maint', ', 'name': 'xterm', 'clients': 0}) done
2019-06-13 10:54:25,152 reply_handler()
2019-06-13 10:54:25,152 update_txt({'display': ':12', 'username': 'maint', ', 'name': 'xterm', 'clients': 0}) done
2019-06-13 10:54:25,155 watching for applications menu changes in:
2019-06-13 10:54:25,156  '/usr/local/share/applications'
2019-06-13 10:54:25,156  '/usr/share/applications'
2019-06-13 10:54:25,267 5.8GB of system memory
2019-06-13 10:54:27,945 peer: (0, -1, -1)
2019-06-13 10:54:27,945 new_connection((<flags G_IO_IN of type GLib.IOCondiEAM, proto=0, laddr=('0.0.0.0', 12000)>)) sock=<socket.socket fd=26, family 12000), raddr=('10.0.4.50', 59934)>, socket_info=('0.0.0.0', 12000), timeo
2019-06-13 10:54:27,946 SocketConnection(<socket.socket fd=26, family=Addre), raddr=('10.0.4.50', 59934)>, ('10.0.3.198', 12000), ('10.0.4.50', 59934)
2019-06-13 10:54:27,946 Connection(('10.0.4.50', 59934), 'tcp', None)
2019-06-13 10:54:27,946 handle_new_connection(tcp socket: 10.0.3.198:12000 tKind.SOCK_STREAM, proto=0, laddr=('10.0.3.198', 12000), raddr=('10.0.4.50'sockname=('10.0.3.198', 12000), target=('10.0.4.50', 59934)
2019-06-13 10:54:28,998 socket tcp socket: 10.0.3.198:12000 <- 10.0.4.50:59
2019-06-13 10:54:28,998 may_wrap_socket: no data, not wrapping
2019-06-13 10:54:28,998 may_wrap_socket(..)=(True, tcp socket: 10.0.3.198:1
2019-06-13 10:54:28,998 log_new_connection(tcp socket: 10.0.3.198:12000 <- ction'>, sock=<socket.socket fd=26, family=AddressFamily.AF_INET, type=Sock4)>, sockname=('10.0.3.198', 12000), address=('10.0.4.50', 59934), peername
2019-06-13 10:54:28,998 New tcp connection received from 10.0.4.50:59934 on
2019-06-13 10:54:28,998 make_protocol(tcp, tcp socket: 10.0.3.198:12000 <- t 0x7fae18dff0d0>)
2019-06-13 10:54:28,999 io_thread_loop(read, <bound method Protocol._read o
2019-06-13 10:54:29,099 untilConcludes(<bound method Connection.is_active oetry of tcp socket: 10.0.3.198:12000 <- 10.0.4.50:59934>, <built-in method meout
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 1
    return f(*a, **kw)
socket.timeout: timed out
2019-06-13 10:54:29,199 untilConcludes(<bound method Connection.is_active oetry of tcp socket: 10.0.3.198:12000 <- 10.0.4.50:59934>, <built-in method meout

Using the Python Client Xpra-x86_64_Setup_3.0-r22817, we get the below logs and the same behaviour as the HTML 5 Client.

2019-06-13 15:57:12,476 xpra is ready.
2019-06-13 15:57:18,667 printer forwarding enabled using postscript and pdf
2019-06-13 15:57:18,674 reply_handler()
2019-06-13 15:57:18,675 update_txt({'display': ':12', 'username': 'maint', 'uuid': '016df33c68354c4fb37511c3dbc73056', 'platform': 'linux', 'type': 'seamless', 'name': 'xterm', 'clients': 0}) done
2019-06-13 15:57:18,675 reply_handler()
2019-06-13 15:57:18,675 update_txt({'display': ':12', 'username': 'maint', 'uuid': '016df33c68354c4fb37511c3dbc73056', 'platform': 'linux', 'type': 'seamless', 'name': 'xterm', 'clients': 0}) done
2019-06-13 15:57:18,675 reply_handler()
2019-06-13 15:57:18,675 update_txt({'display': ':12', 'username': 'maint', 'uuid': '016df33c68354c4fb37511c3dbc73056', 'platform': 'linux', 'type': 'seamless', 'name': 'xterm', 'clients': 0}) done
2019-06-13 15:57:18,680 watching for applications menu changes in:
2019-06-13 15:57:18,680  '/usr/local/share/applications'
2019-06-13 15:57:18,680  '/usr/share/applications'
2019-06-13 15:57:18,791 5.8GB of system memory
2019-06-13 15:57:19,364 peer: (0, -1, -1)
2019-06-13 15:57:19,365 new_connection((<flags G_IO_IN of type GLib.IOCondition>, <socket.socket fd=4, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('0.0.0.0', 12000)>)) sock=<socket.socket fd=26, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('10.0.3.198', 12000), raddr=('10.0.4.50', 50982)>, socket_info=('0.0.0.0', 12000), timeout=0.1, address=('10.0.4.50', 50982), peername=('10.0.4.50', 50982). timeout=0.1
2019-06-13 15:57:19,365 SocketConnection(<socket.socket fd=26, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('10.0.3.198', 12000), raddr=('10.0.4.50', 50982)>, ('10.0.3.198', 12000), ('10.0.4.50', 50982), ('10.0.4.50', 50982), 'tcp', None)
2019-06-13 15:57:19,365 Connection(('10.0.4.50', 50982), 'tcp', None)
2019-06-13 15:57:19,365 handle_new_connection(tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982, <socket.socket fd=26, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('10.0.3.198', 12000), raddr=('10.0.4.50', 50982)>, ('10.0.4.50', 50982), 'tcp', ('10.0.4.50', 50982), ('0.0.0.0', 12000)) sockname=('10.0.3.198', 12000), target=('10.0.4.50', 50982)
2019-06-13 15:57:20,417 socket tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982 peek: got 0 bytes
2019-06-13 15:57:20,417 may_wrap_socket: no data, not wrapping
2019-06-13 15:57:20,417 may_wrap_socket(..)=(True, tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982, b'')
2019-06-13 15:57:20,417 log_new_connection(tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982, ('0.0.0.0', 12000)) type=<class 'xpra.net.bytestreams.SocketConnection'>, sock=<socket.socket fd=26, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('10.0.3.198', 12000), raddr=('10.0.4.50', 50982)>, sockname=('10.0.3.198', 12000), address=('10.0.4.50', 50982), peername=('10.0.4.50', 50982)
2019-06-13 15:57:20,417 New tcp connection received from 10.0.4.50:50982 on 0.0.0.0:12000
2019-06-13 15:57:20,417 make_protocol(tcp, tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982, <function ServerCore.make_protocol.<locals>.xpra_protocol_class at 0x7f20063c00d0>)
2019-06-13 15:57:20,418 io_thread_loop(read, <bound method Protocol._read of Protocol(tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982)>) loop starting
2019-06-13 15:57:20,518 untilConcludes(<bound method Connection.is_active of tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982>, <bound method Connection.can_retry of tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982>, <built-in method recv of socket object at 0x7f2008e08dc8>, (65536,), {}) timed out, retry=socket.timeout
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 116, in untilConcludes
    return f(*a, **kw)
socket.timeout: timed out

Trying to initiate the Python client through the cmd, get the below logs and the client does not connect

bled=['rencode', 'bencode']
2019-06-13 16:05:42,586 write_format_thread_loop starting
2019-06-13 16:05:42,603 next_packet() packets in queues: priority=0, ordinary=1,
 mouse=False
2019-06-13 16:05:42,618 io_thread_loop(write, <bound method Protocol._write of P
rotocol(named-pipe:namedpipe://12000/)>) loop starting
2019-06-13 16:05:42,623 pipe_write: 7473 bytes
2019-06-13 16:05:42,626 WriteFile(..)=0, len=0
2019-06-13 16:05:42,628 WriteFile: INVALID_HANDLE
2019-06-13 16:05:42,643 bwitem(<gtk.Menu object at 0x8053460 (GtkMenu at 0x3fef9
00)>, 0)
2019-06-13 16:05:42,743 io_thread_loop(read, <bound method Protocol._read of Pro
tocol(named-pipe:namedpipe://12000/)>) loop starting
2019-06-13 16:05:42,746 ReadFile(..)=0, len=0
2019-06-13 16:05:42,746 ReadFile: INVALID_HANDLE
0f\x0b\xbay\xd9',), {}) failed to write buffer to named pipe handle 184467440737
09551615, retry=False
Traceback (most recent call last):
  File "./xpra/net/bytestreams.py", line 116, in untilConcludes
  File "./xpra/platform/win32/namedpipes/connection.py", line 139, in _pipe_writ
e
Exception: failed to write buffer to named pipe handle 18446744073709551615
2019-06-13 16:06:48,214 untilConcludes(<bound method NamedPipeConnection._pipe_w
rite of named-pipe:namedpipe://12000/>, ) exception: failed to write buffer to n
amed pipe handle 18446744073709551615, error code=6
Traceback (most recent call last):
  File "./xpra/platform/win32/namedpipes/connection.py", line 85, in untilConclu
des
  File "./xpra/net/bytestreams.py", line 182, in untilConcludes
  File "./xpra/net/bytestreams.py", line 116, in untilConcludes
  File "./xpra/platform/win32/namedpipes/connection.py", line 139, in _pipe_writ
e
Exception: failed to write buffer to named pipe handle 18446744073709551615
2019-06-13 16:06:48,219 Error: write connection named-pipe:namedpipe://12000/ re
set
2019-06-13 16:06:48,221  failed to write buffer to named pipe handle 18446744073
709551615: 6
Traceback (most recent call last):
  File "./xpra/net/protocol.py", line 643, in _io_thread_loop
  File "./xpra/net/protocol.py", line 670, in _write
  File "./xpra/net/protocol.py", line 686, in write_items
  File "./xpra/net/protocol.py", line 705, in write_buffers
  File "./xpra/net/protocol.py", line 716, in con_write
  File "./xpra/platform/win32/namedpipes/connection.py", line 121, in write
  File "./xpra/net/bytestreams.py", line 190, in _write
  File "./xpra/platform/win32/namedpipes/connection.py", line 91, in untilConclu
des
IOError: failed to write buffer to named pipe handle 18446744073709551615: 6
2019-06-13 16:06:48,231 connection lost: write connection named-pipe:namedpipe:/
/12000/ reset
2019-06-13 16:06:48,231 Protocol.close() closed=False, connection=named-pipe:nam
edpipe://12000/
2019-06-13 16:06:48,234 Protocol.close() calling <bound method NamedPipeConnecti
on.close of named-pipe:namedpipe://12000/>
2019-06-13 16:06:48,234 named-pipe:namedpipe://12000/.close()
2019-06-13 16:06:48,236 terminate_queue_threads()
2019-06-13 16:06:48,239 Protocol.close() done
2019-06-13 16:06:48,239 check_server_echo(0) last=True, server_ok=True (last_pin
g_echoed_time=0)
2019-06-13 16:06:48,239 Error: failed to receive anything, not an xpra server?
2019-06-13 16:06:48,241   could also be the wrong protocol, username, password o
r port
2019-06-13 16:06:48,241   or the session was not found
2019-06-13 16:06:48,244 Connection lost
2019-06-13 16:06:48,246 Protocol.close() closed=True, connection=None
2019-06-13 16:06:48,284 WaitForSingleObject(..)=TIMEOUT, len=0
2019-06-13 16:06:48,284 pipe_read: 0 bytes
C:\Program Files\Xpra>

In both cases, the client will eventually connect. But for the python client, it will fail to connect(2/3 times failed).

Network Drivers of the VM

00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Device 1234:1111
00:03.0 SCSI storage controller: XenSource, Inc. Xen Platform Device (rev 02)

We will try to reproduce with some older version soon, and we may even try a tcp dump.


Fri, 14 Jun 2019 00:29:27 GMT - zaveri: attachment set


Fri, 14 Jun 2019 00:30:15 GMT - zaveri:

As we were performing some other testing, we found the below exception

During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/protocol.py", line 643, in _io_thread_loop
    while not self._closed and callback():
  File "/usr/lib64/python3.7/site-packages/xpra/net/protocol.py", line 722, in _read
    buf = self._conn.read(self.read_buffer_size)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 327, in read
    return self._read(self._socket.recv, n)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 197, in _read
    r = self.untilConcludes(*args)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 182, in untilConcludes
    return untilConcludes(self.is_active, self.can_retry, *args)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 118, in untilConcludes
    retry = can_retry_cb(e)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 179, in can_retry
    return can_retry(e)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 106, in can_retry
    raise ConnectionClosedException(e)
xpra.net.common.ConnectionClosedException: [Errno 9] Bad file descriptor
2019-06-13 16:55:19,650 connection lost: invalid packet format, HTTP GET request
2019-06-13 16:55:19,650 Protocol.close() closed=True, connection=None
2019-06-13 16:55:23,652 flush_then_close: wait_for_packet_sent() close_and_release()
2019-06-13 16:55:23,652 Protocol.close() closed=True, connection=None
2019-06-13 16:55:23,652 flush_then_close: done, callback=None

XPRA INFO -- attached txt file.


Fri, 14 Jun 2019 03:36:01 GMT - Antoine Martin:

First, your server command line starts on port 14000 but your client connects to port 12000. Make sure to always include the command lines with the command output.

From the point of XPRA is ready until the first traceback, here are the logs from the server.

That traceback is normal. Do not stop there. In debug mode, you will be seeing a lot more details, including stacktraces. In this case, the server is triggering a timeout waiting to send or receive stuff. This is not an error, it will just retry.

2019-06-13 10:54:27,946 handle_new_connection(tcp socket: 10.0.3.198:12000 tKind.SOCK_STREAM, proto=0, laddr=('10.0.3.198', 12000), raddr=('10.0.4.50'sockname=('10.0.3.198', 12000), target=('10.0.4.50', 59934) 2019-06-13 10:54:28,998 may_wrap_socket: no data, not wrapping

What's strange here is that we should be receiving some initial data with the connection. You can try increasing the delay to see if that helps:

XPRA_PEEK_TIMEOUT=5 xpra start ...

The default is to wait just 1 second for some data to arrive. When the server doesn't get any data, it will use the default TCP mode, which is fine for a native client but not for the html5 client. Using bind-ws instead of bind-tcp may workaround this problem. When you do this, you can still connect the native client but you need to use a ws connection string: xpra attach ws://IP:port/.

Trying to initiate the Python client through the cmd, get the below logs and the client does not connect

You're using an invalid URI syntax, which ends up being parsed as a named-pipe: named-pipe:namedpipe://12000/.

xpra.net.common.ConnectionClosedException: [Errno 9] Bad file descriptor

This one looks harmless, with debug logging turned off it should end up being handled as a normal "connection is closed" event.


Fri, 14 Jun 2019 15:09:52 GMT - Antoine Martin:

Please also try with a python2 xpra server. This could be caused by some subtle socket API change between python2 and python3.


Fri, 14 Jun 2019 17:51:19 GMT - Antoine Martin:

Another thing worth trying is to host the xpra html5 client on a separate server (apache, nginx, etc).


Mon, 22 Jul 2019 16:06:11 GMT - Antoine Martin: priority changed

The 3.0 release is getting closer, we need to make sure this is fixed. (I cannot reproduce)


Thu, 01 Aug 2019 11:50:19 GMT - Smo: owner changed

I've tried to reproduce this multiple ways with different clients including windows.

I can't seem to find a way to get this error so I believe this should be closed for now until it shows up again.


Thu, 01 Aug 2019 12:58:05 GMT - Antoine Martin: status changed; resolution set

Thanks.


Sat, 23 Jan 2021 05:48:02 GMT - migration script:

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