For reference: both the server and client are Fedora 26 (I'm upgrading next week) running trunk r19194 built from source
I've ran into this issue semi-infrequently, and this time happened to actually be running with --no-daemon
while playing around with start-desktop
. Sometimes after disconnecting a client on a session that's been around for a while (at least an hour), It'll refuse to let the client connect. In the past I've not run into this much since I'm always stopping and starting a session, but every now and then it happens - I usually run into it in the normal start method.
The server side traceback is as follows:
2018-05-04 13:52:10,830 unsupported type: <type 'dbus.UInt32'> in 'info-response' packet->[1]->value for key='notifications'->value for key='active'->[0] 2018-05-04 13:52:10,830 unsupported type: <type 'dbus.UInt32'> in 'info-response' packet->[1]->value for key='notifications'->value for key='active'->[1] 2018-05-04 13:52:10,830 unsupported type: <type 'dbus.UInt32'> in 'info-response' packet->[1]->value for key='notifications'->value for key='active'->[2] 2018-05-04 13:52:10,830 unsupported type: <type 'dbus.UInt32'> in 'info-response' packet->[1]->value for key='notifications'->value for key='active'->[3] 2018-05-04 13:52:10,830 unsupported type: <type 'dbus.UInt32'> in 'info-response' packet->[1]->value for key='notifications'->value for key='active'->[4] 2018-05-04 13:52:10,830 unsupported type: <type 'dbus.UInt32'> in 'info-response' packet->[1]->value for key='notifications'->value for key='active'->[5] 2018-05-04 13:52:10,831 unsupported type: <type 'long'> in 'info-response' packet->[1]->value for key='cursor'->value for key='default_size' 2018-05-04 13:52:10,831 unsupported type: <type 'long'> in 'info-response' packet->[1]->value for key='cursor'->value for key='serial' 2018-05-04 13:52:10,841 unsupported type: <type 'unicode'> in 'info-response' packet->[1]->value for key='network'->value for key='interfaces'->[0] 2018-05-04 13:52:10,841 unsupported type: <type 'unicode'> in 'info-response' packet->[1]->value for key='network'->value for key='interfaces'->[1] 2018-05-04 13:52:10,841 unsupported type: <type 'unicode'> in 'info-response' packet->[1]->value for key='network'->value for key='interfaces'->[2] 2018-05-04 13:52:10,841 unsupported type: <type 'unicode'> in 'info-response' packet->[1]->value for key='network'->value for key='interfaces'->[3] 2018-05-04 13:52:10,845 unsupported type: <type 'unicode'> in 'info-response' packet->[1]->value for key='network'->value for key='lz4'->value for key='version' 2018-05-04 13:52:10,846 unsupported type: <type 'long'> in 'info-response' packet->[1]->value for key='network'->value for key='ssl'->value for key='openssl'->value for key='version-number' 2018-05-04 13:52:10,847 unsupported type: <type 'unicode'> in 'info-response' packet->[1]->value for key='network'->value for key='gateways'->value for key='INET6'->[0]->[0] 2018-05-04 13:52:10,847 unsupported type: <type 'unicode'> in 'info-response' packet->[1]->value for key='network'->value for key='gateways'->value for key='INET6'->[0]->[1] 2018-05-04 13:52:10,848 unsupported type: <type 'unicode'> in 'info-response' packet->[1]->value for key='network'->value for key='gateways'->value for key='INET'->[0]->[0] 2018-05-04 13:52:10,849 unsupported type: <type 'unicode'> in 'info-response' packet->[1]->value for key='network'->value for key='gateways'->value for key='INET'->[0]->[1] 2018-05-04 13:52:10,850 unsupported type: <type 'unicode'> in 'info-response' packet->[1]->value for key='server'->value for key='uuid' 2018-05-04 13:52:10,882 Error: error in network packet write/format 2018-05-04 13:52:10,882 type <type 'dbus.UInt32'> not handled Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 352, in _write_format_thread_loop self._add_packet_to_queue(*gpc()) File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 364, in _add_packet_to_queue chunks = self.encode(packet) File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 558, in encode main_packet, proto_flags = self._encoder(packet) File "/usr/lib64/python2.7/site-packages/xpra/net/packet_encoding.py", line 84, in do_rencode return rencode_dumps(data), FLAGS_RENCODE File "rencode/rencode.pyx", line 334, in rencode._rencode.dumps File "rencode/rencode.pyx", line 314, in rencode._rencode.encode File "rencode/rencode.pyx", line 247, in rencode._rencode.encode_list File "rencode/rencode.pyx", line 317, in rencode._rencode.encode File "rencode/rencode.pyx", line 264, in rencode._rencode.encode_dict File "rencode/rencode.pyx", line 317, in rencode._rencode.encode File "rencode/rencode.pyx", line 259, in rencode._rencode.encode_dict File "rencode/rencode.pyx", line 314, in rencode._rencode.encode File "rencode/rencode.pyx", line 247, in rencode._rencode.encode_list File "rencode/rencode.pyx", line 320, in rencode._rencode.encode Exception: type <type 'dbus.UInt32'> not handled
The client prints no error beyond "disconnected".
I wish I could give you steps to reproduce, but this has happened to me so infrequently that I haven't been able to narrow it down.
(fix version)
I believe this should be fixed in r19195.
This would have been hard to trigger as you would need a notification that replaces an earlier one. We would then store the notification id as a dbus.UInt32
rather than a plain python int, and this cannot be serialized - why python-dbus exposes such unhelpful datatypes I do not know.
This was a rare one indeed, I doubt I'll be able to run into this again. As such I'm going to close this. If I run into it again, I know where to go.
As an aside, I think this was made easier to trigger somewhat recently because of all the added notifications - between notification forwarding and more popular desktop notifications in web-apps, desktop notifications are becoming quite popular. For better or for worse.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1829