Context Navigation

← Previous Ticket
Next Ticket →

#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 Antoine Martin

Owner:	changed from Antoine Martin to onlyjob

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)

comment:2 Changed 7 years ago by 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...

comment:3 Changed 7 years ago by onlyjob

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

comment:4 Changed 7 years ago by 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)

Last edited 7 years ago by Antoine Martin (previous) (diff)

comment:5 Changed 7 years ago by 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"...