Xpra: Ticket #633: client crash on maximising large window

Xpra 0.13.8 (client) sometimes crashes when application is maximised on large multi-monitor desktop:

desktop size is 4800x2560 with 1 screen(s):
  ':0.0' (1265x675 mm)
    DFP5 1680x1050 at 0x755 (474x296 mm)
    DFP10 1440x2560 at 1680x0 (597x336 mm)
    DFP1 1680x1050 at 3120x644 (474x296 mm)
server: Linux debian 7.6 , Xpra version 0.13.8 (r7148)
[...]
Received uninterpretable nonsense: 'P\x01\x00\x07\x02\xe5x\xb0'
2014-08-10 10:20:03,937 connection lost: invalid packet header byte: '0x50' read buffer=0x'P\x01\x00\x07\x02\xe5x\xb0'
Connection lost

I've noticed this with QuiteRSS_0.16.1 when it restored its window on Xpra client with large desktop. Smaller desktops are OK. I should be happy to provide more information as it is easy for me to reproduce.



Sun, 10 Aug 2014 01:29:41 GMT - Antoine Martin: owner changed

Are you using rgb encoding? What compression level? Do you have lz4? What xpra version? Does this also happen with trunk? (the error message from trunk would be more helpful I think)


Sun, 10 Aug 2014 01:39:42 GMT - onlyjob:

Yes I've been using RGB when it happened (no compression level on RGB). Sorry, I do not know if I have "lz4" or how to check for it... Xpra version 0.13.8 (already mentioned). I can't test trunk at this time due to lack of time, sorry...


Sun, 10 Aug 2014 01:44:58 GMT - onlyjob:

Just reproduced with H.264 -- the error message is the same.


Sun, 10 Aug 2014 02:15:23 GMT - Antoine Martin:

I believe you're hitting the packet limit because you're using RGB without compression. r7225 probably fixes that by bumping the hard limit.

Failing that, please post the exact command line. Does it happen with "-z 1"? Can you try PNG or JPEG encodings instead? (testing with h264 is less helpful because the first frame will be using RGB or PNG instead - and it is the first frame that is causing this problem)


I do not know if I have "lz4" or how to check for it


Checking is all explained here: ticket:443#comment:1 and lz4 vs zlib is compared here: wiki/PacketEncoding

BTW, seeing how slow zlib is and that Debian still does not package python-lz4, it is understandable that you would be turning compression off. Version 0.14 adds support for python-lzo and the Debian packages will depend on it (see r6992). python-lzo isn't as good as python-lz4 but at least it is available in Debian and will allow you to get both good enough compression and performance.

More and more (especially in 0.14) the code is being tuned to assume that a decent compression library is present (lz4 or lz0), which means that using zlib will become a "legacy" configuration and that lz4 should often be preferred to no-compression. (this has other security benefits too: #614)


Sun, 10 Aug 2014 03:00:49 GMT - onlyjob:

Yes it happens with -z 1. I could not reproduce with PNG or JPEG encodings. Many thanks for information about packet compression. I'll add "python-lzo" to Recommends and see if I can package "python-lz4"...


Mon, 11 Aug 2014 04:31:45 GMT - Antoine Martin: priority changed

Does r7225 fix things? Can I backport it and close this ticket?


Mon, 11 Aug 2014 09:07:10 GMT - onlyjob: status changed; resolution set

Yes r7225 appears to fix this issue. Thanks.


Sat, 23 Jan 2021 05:01:28 GMT - migration script:

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