client crash on maximising large window

[totaam]

Issue migrated from trac ticket # 633

component: client | priority: critical | resolution: fixed

2014-08-10 01:38:32: onlyjob created the issue

---

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 (7148)

[...]

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.

[totaam]

2014-08-10 02:29:41: totaam changed owner from antoine to onlyjob

[totaam]

2014-08-10 02:29:41: totaam commented

---

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)

[totaam]

2014-08-10 02:39:43: onlyjob commented

---

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...

[totaam]

2014-08-10 02:44:59: onlyjob commented

---

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

[totaam]

2014-08-10 03:15:23: totaam commented

---

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
[[BR]]
Checking is all explained here:
#443#comment:1
and lz4 vs zlib is compared here: 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)

[totaam]

2014-08-10 04:00:50: onlyjob commented

---

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"...

[totaam]

2014-08-11 05:31:46: totaam changed priority from major to critical

[totaam]

2014-08-11 05:31:46: totaam commented

---

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

[totaam]

2014-08-11 10:07:10: onlyjob changed status from new to closed

[totaam]

2014-08-11 10:07:10: onlyjob changed resolution from ** to fixed

[totaam]

2014-08-11 10:07:10: onlyjob commented

---

Yes r7225 appears to fix this issue. Thanks.