#1829 closed defect (fixed)
Rencode traceback - doesn't allow client to re-attach
Reported by: | J. Max Mena | Owned by: | J. Max Mena |
---|---|---|---|
Priority: | major | Milestone: | 2.3 |
Component: | server | Version: | trunk |
Keywords: | Cc: |
Description
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.
Change History (4)
comment:1 Changed 3 years ago by
Version: | 2.2.x → trunk |
---|
comment:2 Changed 3 years ago by
Owner: | changed from Antoine Martin to J. Max Mena |
---|
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.
comment:3 Changed 3 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
comment:4 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1829
(fix version)