Rencode traceback - doesn't allow client to re-attach

[J. Max Mena]

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.

[J. Max Mena]

(fix version)

[Antoine Martin]

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.

[J. Max Mena]

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.

[migration script]

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