#633 closed defect (fixed)
client crash on maximising large window
Reported by: | onlyjob | Owned by: | onlyjob |
---|---|---|---|
Priority: | critical | Milestone: | 0.14 |
Component: | client | Version: | trunk |
Keywords: | Cc: |
Description
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.
Change History (8)
comment:1 Changed 7 years ago by
Owner: | changed from Antoine Martin to onlyjob |
---|
comment:2 Changed 7 years ago by
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...
comment:4 Changed 7 years ago by
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)
comment:5 Changed 7 years ago by
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"...
comment:6 Changed 7 years ago by
Priority: | major → critical |
---|
Does r7225 fix things? Can I backport it and close this ticket?
comment:7 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Yes r7225 appears to fix this issue. Thanks.
comment:8 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/633
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)