Using Windows 8.1 x64 and Firefox 37.0.2 against a Fedora 21 0.15.0 r9285 server:
2015-05-08 16:20:26,605 New tcp connection received from ('10.0.11.124', 64039) 2015-05-08 16:20:26,723 client connection from 10.0.11.124:64039 forwarded to proxy server on 127.0.0.1:52166 2015-05-08 16:20:27,129 New tcp connection received from ('10.0.11.124', 64040) 2015-05-08 16:20:27,247 client connection from 10.0.11.124:64040 forwarded to proxy server on 127.0.0.1:52166 261: 127.0.0.1: Plain non-SSL (ws://) WebSocket connection 261: 127.0.0.1: Version hybi-13, base64: 'False' 261: connecting to: 127.0.0.1:2200 2015-05-08 16:20:27,250 New tcp connection received from ('127.0.0.1', 48051) 2015-05-08 16:20:27,297 Handshake complete; enabling connection 2015-05-08 16:20:27,300 HTML5 Microsoft Windows client version 0.15.0 2015-05-08 16:20:27,300 using h264 as primary encoding, also available: jpeg, png, rgb32 2015-05-08 16:20:27,301 client root window size is 1658x845 with 1 displays: 2015-05-08 16:20:27,301 'HTML' (439x224 mm - DPI: 95x95) 2015-05-08 16:20:27,302 Canvas 2015-05-08 16:20:27,302 best resolution matching 1658x845 is unchanged: 1680x1050 2015-05-08 16:20:27,304 keyboard mapping already configured (skipped) 2015-05-08 16:20:29,573 failed to parse bencode packet: invalid literal for long() with base 10: 'NaN' Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 740, in do_read_parse_thread_loop packet = decode(data, protocol_flags) File "/usr/lib64/python2.7/site-packages/xpra/net/packet_encoding.py", line 169, in decode packet, l = bdecode(data) File "xpra/net/bencode/cython_bencode.pyx", line 117, in xpra.net.bencode.cython_bencode.bdecode (xpra/net/bencode/cython_bencode.c:2437) File "xpra/net/bencode/cython_bencode.pyx", line 100, in xpra.net.bencode.cython_bencode.decode (xpra/net/bencode/cython_bencode.c:2164) File "xpra/net/bencode/cython_bencode.pyx", line 76, in xpra.net.bencode.cython_bencode.decode_list (xpra/net/bencode/cython_bencode.c:1645) File "xpra/net/bencode/cython_bencode.pyx", line 100, in xpra.net.bencode.cython_bencode.decode (xpra/net/bencode/cython_bencode.c:2164) File "xpra/net/bencode/cython_bencode.pyx", line 76, in xpra.net.bencode.cython_bencode.decode_list (xpra/net/bencode/cython_bencode.c:1645) File "xpra/net/bencode/cython_bencode.pyx", line 104, in xpra.net.bencode.cython_bencode.decode (xpra/net/bencode/cython_bencode.c:2212) File "xpra/net/bencode/cython_bencode.pyx", line 46, in xpra.net.bencode.cython_bencode.decode_int (xpra/net/bencode/cython_bencode.c:1069) ValueError: invalid literal for long() with base 10: 'NaN' 2015-05-08 16:20:29,575 Disconnecting client Protocol(SocketConnection(('127.0.0.1', 2200) - ('127.0.0.1', 48051))): packet index=0, packet size=44, buffer size=44, error=invalid literal for long() with base 10: 'NaN' 2015-05-08 16:20:29,577 xpra client disconnected. 2015-05-08 16:20:29,592 New tcp connection received from ('10.0.11.124', 64041) Exception in thread web-proxy-for-Protocol(SocketConnection(('10.0.32.138', 2200) - ('10.0.11.124', 64041))): Traceback (most recent call last): File "/usr/lib64/python2.7/threading.py", line 813, in __bootstrap_inner self.run() File "/usr/lib64/python2.7/threading.py", line 766, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/xpra/server/server_core.py", line 395, in run_proxy self.start_tcp_proxy(proto, data) File "/usr/lib64/python2.7/site-packages/xpra/server/server_core.py", line 408, in start_tcp_proxy client_connection = proto.steal_connection(temp_read_buffer.put) File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 885, in steal_connection assert not self._closed AssertionError
Blocker for 0.15 release.
Note: if you run with -d network
you should be able to see the full packet data hexlified, from there you should be able to figure out which part contains NaN
(which is obviously not a valid number).
(r9286 avoids the bottom stacktrace - backport to v0.15.x in r9287)
Reattempted with -d network
Captured the relevant log bits (with the traceback included):
2015-05-08 22:21:13,739 failed to parse bencode packet: invalid literal for long() with base 10: 'NaN' Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 740, in do_read_parse_thread_loop packet = decode(data, protocol_flags) File "/usr/lib64/python2.7/site-packages/xpra/net/packet_encoding.py", line 169, in decode packet, l = bdecode(data) File "xpra/net/bencode/cython_bencode.pyx", line 117, in xpra.net.bencode.cython_bencode.bdecode (xpra/net/bencode/cython_bencode.c:2437) File "xpra/net/bencode/cython_bencode.pyx", line 100, in xpra.net.bencode.cython_bencode.decode (xpra/net/bencode/cython_bencode.c:2164) File "xpra/net/bencode/cython_bencode.pyx", line 76, in xpra.net.bencode.cython_bencode.decode_list (xpra/net/bencode/cython_bencode.c:1645) File "xpra/net/bencode/cython_bencode.pyx", line 100, in xpra.net.bencode.cython_bencode.decode (xpra/net/bencode/cython_bencode.c:2164) File "xpra/net/bencode/cython_bencode.pyx", line 76, in xpra.net.bencode.cython_bencode.decode_list (xpra/net/bencode/cython_bencode.c:1645) File "xpra/net/bencode/cython_bencode.pyx", line 104, in xpra.net.bencode.cython_bencode.decode (xpra/net/bencode/cython_bencode.c:2212) File "xpra/net/bencode/cython_bencode.pyx", line 46, in xpra.net.bencode.cython_bencode.decode_int (xpra/net/bencode/cython_bencode.c:1069) ValueError: invalid literal for long() with base 10: 'NaN' 2015-05-08 22:21:13,756 failed to parse bencode packet: 6c31333a627574746f6e2d616374696f6e6932656934656931656c694e614e65694e614e65656c656c6565 2015-05-08 22:21:13,756 will process ui packet gibberish 2015-05-08 22:21:13,756 Received uninterpretable nonsense from Protocol(SocketConnection(('127.0.0.1', 2200) - ('127.0.0.1', 34481))): packet index=0, packet size=43, buffer size=94, error=invalid literal for long() with base 10: 'NaN' 2015-05-08 22:21:13,757 data: 'l13:button-actioni2ei4ei1eliNaNeiNaNeelelee' 2015-05-08 22:21:13,757 disconnect_client(Protocol(SocketConnection(('127.0.0.1', 2200) - ('127.0.0.1', 34481))), packet index=0, packet size=43, buffer size=94, error=invalid literal for long() with base 10: 'NaN', ()) 2015-05-08 22:21:13,757 disconnect_protocol(Protocol(SocketConnection(('127.0.0.1', 2200) - ('127.0.0.1', 34481))), packet index=0, packet size=43, buffer size=94, error=invalid literal for long() with base 10: 'NaN', ()) 2015-05-08 22:21:13,757 Disconnecting client Protocol(SocketConnection(('127.0.0.1', 2200) - ('127.0.0.1', 34481))): packet index=0, packet size=43, buffer size=94, error=invalid literal for long() with base 10: 'NaN'
Hope that helps
I can provide more logs if needed. (although I'll be out and about tomorrow, Saturday the 9th PST and Sunday is Mother's Day)
EDIT: for what it's worth, scrolling works fine in Chrome 42
It looks to me like Firefox is not sending the x and y coordinates for the mouse scroll button events (it was not at all obvious to me that this was how you were scrolling until I saw the packet dump).
From what I am reading, it is not possible (or rather, not advisable) to try to get the current mouse coordinates in Javascript, so this makes the fix slightly more complicated: we need to keep track of the current mouse position from all mouse move events so that we can send it with these click (scroll) events. (we then just check if the x and y values are isNaN
and substitute the last known coordinates if they are)
@josh: am-i-rite?
@antoine: confirmed. sounds like the best solution.
Pushed fix in r9290, tested with Firefox on OS X and working now for me.
@maxmylyn: can you see if the problem is fixed for you?
Backport to v0.15.x in r9293. Works-for-me.
@maxmylyn: can you still break it?
Using the 0.15.0 tagged branch builds (r9303) I am unable to crash with scrolling using Firefox.
Using my trunk(r9303) builds, I am still able to crash by scrolling in Chrome and Firefox.
a -d network
produces the following output and traceback:
2015-05-11 09:47:04,283 failed to encode packet: ['draw', 3, 1054, 0, 1, 665, 'rgb32', 'x^\xb3\xc9M\xcd\xcd/\xaaTH,Q0\xa80O3IKNL4211\xb7\xb0\x03\x00x\x00\x086', 20, 4, {'zlib': 4, 'rgb_format': 'RGBX'}] Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 479, in encode main_packet, proto_version = self._encoder(packet) File "/usr/lib64/python2.7/site-packages/xpra/net/packet_encoding.py", line 64, in do_bencode return bencode(data), 0 File "xpra/net/bencode/cython_bencode.pyx", line 208, in xpra.net.bencode.cython_bencode.bencode (xpra/net/bencode/cython_bencode.c:4234) ValueError: cannot encode '['draw', 3, 1054, 0, 1, 665, 'rgb32', 'x^\xb3\xc9M\xcd\xcd/\xaaTH,Q0\xa80O3IKNL4211\xb7\xb0\x03\x00x\x00\x086', 20, 4, {'zlib': 4, 'rgb_format': 'RGBX'}]': 'utf8' codec can't decode byte 0xb3 in position 2: invalid start byte 2015-05-11 09:47:04,295 internal error: error in network packet write/format Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 278, in _write_format_thread_loop self._add_packet_to_queue(*self._get_packet_cb()) File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 288, in _add_packet_to_queue chunks, proto_flags = self.encode(packet) File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 487, in encode raise e ValueError: cannot encode '['draw', 3, 1054, 0, 1, 665, 'rgb32', 'x^\xb3\xc9M\xcd\xcd/\xaaTH,Q0\xa80O3IKNL4211\xb7\xb0\x03\x00x\x00\x086', 20, 4, {'zlib': 4, 'rgb_format': 'RGBX'}]': 'utf8' codec can't decode byte 0xb3 in position 2: invalid start byte 2015-05-11 09:47:04,295 connection lost: error in network packet write/format 2015-05-11 09:47:04,296 close() closed=False 2015-05-11 09:47:04,296 terminate_queue_threads() 2015-05-11 09:47:04,296 read thread: empty marker, exiting 2015-05-11 09:47:04,296 will process ui packet connection-lost 2015-05-11 09:47:04,296 write thread: empty marker, exiting 2015-05-11 09:47:04,297 close() closed=True 2015-05-11 09:47:04,297 close() closed=True 2015-05-11 09:47:04,297 process_connection_lost(Protocol(None), ['connection-lost']) 2015-05-11 09:47:04,297 io_thread_loop(write, <bound method Protocol._write of Protocol(None)>) loop ended, closed=True 2015-05-11 09:47:04,297 Connection lost 2015-05-11 09:47:04,303 cleanup_source(Protocol(None)) 2015-05-11 09:47:04,303 xpra client disconnected. 17: handler exception: [Errno 107] Transport endpoint is not connected
journalctl -n 200
) also causes a crash in both Chrome and Firefox with the following output(not sure if this is related or should go in a separate ticket):
Traceback (most recent call last): File "xpra/net/bencode/cython_bencode.pyx", line 204, in xpra.net.bencode.cython_bencode.bencode (xpra/net/bencode/cython_bencode.c:4140) 2015-05-11 09:53:35,798 processing packet button-action 2015-05-11 09:53:35,799 will process ui packet button-action File "xpra/net/bencode/cython_bencode.pyx", line 204, in genexpr (xpra/net/bencode/cython_bencode.c:4007) File "xpra/net/bencode/cython_bencode.pyx", line 202, in xpra.net.bencode.cython_bencode.bencode.bytestostr (xpra/net/bencode/cython_bencode.c:3877) File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeDecodeError: 'utf8' codec can't decode byte 0xb3 in position 2: invalid start byte 2015-05-11 09:53:35,801 failed to encode packet: ['draw', 2, 498, 0, 1, 316, 'rgb32', 'x^\xb3\xc9M\xcd\xcd/\xaaTH,Q0\xa80OK1O6I30MN\xb6\xb0\x03\x00x.\x08i', 46, 4, {'zlib': 4, 'rgb_format': 'RGBX'}] Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 479, in encode main_packet, proto_version = self._encoder(packet) File "/usr/lib64/python2.7/site-packages/xpra/net/packet_encoding.py", line 64, in do_bencode return bencode(data), 0 File "xpra/net/bencode/cython_bencode.pyx", line 208, in xpra.net.bencode.cython_bencode.bencode (xpra/net/bencode/cython_bencode.c:4234) ValueError: cannot encode '['draw', 2, 498, 0, 1, 316, 'rgb32', 'x^\xb3\xc9M\xcd\xcd/\xaaTH,Q0\xa80OK1O6I30MN\xb6\xb0\x03\x00x.\x08i', 46, 4, {'zlib': 4, 'rgb_format': 'RGBX'}]': 'utf8' codec can't decode byte 0xb3 in position 2: invalid start byte 2015-05-11 09:53:35,802 internal error: error in network packet write/format Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 278, in _write_format_thread_loop self._add_packet_to_queue(*self._get_packet_cb()) File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 288, in _add_packet_to_queue chunks, proto_flags = self.encode(packet) File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 487, in encode raise e ValueError: cannot encode '['draw', 2, 498, 0, 1, 316, 'rgb32', 'x^\xb3\xc9M\xcd\xcd/\xaaTH,Q0\xa80OK1O6I30MN\xb6\xb0\x03\x00x.\x08i', 46, 4, {'zlib': 4, 'rgb_format': 'RGBX'}]': 'utf8' codec can't decode byte 0xb3 in position 2: invalid start byte 2015-05-11 09:53:35,802 connection lost: error in network packet write/format
Ah, this one is most probably my fault (not sure why it only popped up now): in trying to fix py3k support, I must have borken python2 (and I've already spent a couple of days on this stoopid unicode nonsense).
Probably caused by r9220 or r9219.
r9304 adds a test for this unicode pita.
partial revert which at least gets python2 working again..
all but one test fails..
As of r9308 (r9309 for v0.15.x branch), all tests pass for both python2 and py3k and the html5 client no longer disconnects.
@maxmylyn: back to you! (to see what else I've broken..)
Upped to 9329 0.15.0:
normal fullscreen windows
enabled. And then attempting to open a normal Xpra (using CMD) session caused a traceback:
2015-05-12 09:39:21,354 failed to encode packet: [3, 3, 209, 42, 1, 16, 'rgb24', <read-write buffer ptr 0x7f2c88002380, size 64 at 0x7f2c9c1e8c70>, 3, 4, {'rgb_format': 'BGRX'}] Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 484, in encode main_packet, proto_version = self._encoder(packet) File "/usr/lib64/python2.7/site-packages/xpra/net/packet_encoding.py", line 70, in do_rencode return rencode_dumps(data), FLAGS_RENCODE File "rencode.pyx", line 330, in rencode._rencode.dumps (rencode/rencode.c:4310) File "rencode.pyx", line 310, in rencode._rencode.encode (rencode/rencode.c:4108) File "rencode.pyx", line 243, in rencode._rencode.encode_list (rencode/rencode.c:3110) File "rencode.pyx", line 316, in rencode._rencode.encode (rencode/rencode.c:4159) Exception: type <type 'buffer'> not handled 2015-05-12 09:39:21,355 internal error: error in network packet write/format Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 274, in _write_format_thread_loop self._add_packet_to_queue(*self._get_packet_cb()) File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 284, in _add_packet_to_queue chunks, proto_flags = self.encode(packet) File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 492, in encode raise e Exception: type <type 'buffer'> not handled 2015-05-12 09:39:21,356 Connection lost 2015-05-12 09:39:21,356 xpra client disconnected.
Using latest trunk builds all is fine, except for connecting with a normal Xpra client after using the HTML5 client with normal fullscreen windows
(re-testing to see if I see the same issue on trunk) I get the following print in the server:
Exception in thread web-proxy-for-Protocol(SocketConnection(('10.0.32.138', 2200) - ('10.0.11.124', 52067))): Traceback (most recent call last): File "/usr/lib64/python2.7/threading.py", line 813, in __bootstrap_inner self.run() File "/usr/lib64/python2.7/threading.py", line 766, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/xpra/server/server_core.py", line 395, in run_proxy self.start_tcp_proxy(proto, data) File "/usr/lib64/python2.7/site-packages/xpra/server/server_core.py", line 404, in start_tcp_proxy self._potential_protocols.remove(proto) ValueError: list.remove(x): x not in list
And the client(Win8.1 64-bit r9202) prints over and over:
2015-05-12 09:53:17,017 error processing draw packet Traceback (most recent call last): File "xpra\client\ui_client_base.pyc", line 1974, in _draw_thread_loop File "xpra\client\ui_client_base.pyc", line 2020, in _do_draw File "xpra\client\client_window_base.pyc", line 423, in draw_region File "xpra\client\window_backing_base.pyc", line 473, in draw_region File "xpra\client\window_backing_base.pyc", line 264, in paint_rgb24 File "xpra\client\window_backing_base.pyc", line 175, in process_delta Exception: expected 3376 bytes for 1x844 with rowstride=4 but received 26 (34 co mpressed) 2015-05-12 09:53:17,163 invalid img data <type 'str'>: <memory at 0x7fcc2cea1a68 > 2015-05-12 09:53:17,164 draw error Traceback (most recent call last): File "xpra\client\ui_client_base.pyc", line 2020, in _do_draw File "xpra\client\client_window_base.pyc", line 423, in draw_region File "xpra\client\window_backing_base.pyc", line 473, in draw_region File "xpra\client\window_backing_base.pyc", line 264, in paint_rgb24 File "xpra\client\window_backing_base.pyc", line 175, in process_delta Exception: expected 3376 bytes for 1x844 with rowstride=4 but received 26 (34 co mpressed) 2015-05-12 09:53:17,164 draw error Traceback (most recent call last): File "xpra\client\ui_client_base.pyc", line 2020, in _do_draw File "xpra\client\client_window_base.pyc", line 423, in draw_region File "xpra\client\window_backing_base.pyc", line 473, in draw_region File "xpra\client\window_backing_base.pyc", line 264, in paint_rgb24 File "xpra\client\window_backing_base.pyc", line 175, in process_delta Exception: expected 3376 bytes for 1x844 with rowstride=4 but received 26 (34 co mpressed) 2015-05-12 09:53:17,164 error processing draw packet
If you think this new issue is unrelated to the work on this one, then I can open a separate ticket.
The issues from comment:11 are not likely to be related to the html5 client. (but I don't think we really need a ticket for them unless they persist)
Exception: type <type 'buffer'> not handled
- this one was probably caused by the fix for the bencoder (see comment:10). In this particular case, we do want to copy the data to a "string" - at least for now, in the future it might be better to teach rencode and bencode to handle buffers directly (would save copying the data). Strangely enough, I've not been able to reproduce the problem (though it might be because I test with trunk more than 0.15.x right now), so r9332 should fix this but I will try to reproduce the problem (using -z 0
to turn off compression should help, and turning off memoryview support when testing with trunk) before I apply this fix to the 0.15.x branch
ValueError: list.remove(x): x not in list
: I believe this is fixed in r9331 (will backport to 0.15.x), but again, I have not been able to hit this issue myself during testing! Not sure why. Steps to reproduce would be welcome.
Exception: expected 3376 bytes for 1x844 with rowstride=4 but received 26 (34 compressed)
- this one is probably the result of the buffer bug above. At least I hope.
Just to be clear: are you building from trunk (0.16) or from the 0.15.x branch?
Keyboard randomly broke
ValueError? ..... Steps to reproduce would be welcome
Found a semi-reliable repro using my trunk build:
normal fullscreen windows
enabled
EDIT:
Just to be clear: are you building from trunk (0.16) or from the 0.15.x branch?
I build from both trunk and 0.15.x branch. I've been starting with 0.15.x since we're working for the release, switching to trunk to see if the issue appears there as well.
Link to the numlock ticket: #858
Found a semi-reliable repro using my trunk build: (..)
I have tried and tried again, both with trunk and 0.15, no luck!
Help!
Are the previous buffer errors gone for you? (r9346 applied the fixes to v0.15.x)
Help!
Updated to trunk r9357 and I am no longer able to reproduce this error. It appears to have been resolved; at least for my use case - I will keep an eye out for it.
However running 0.15.0 r9357 I get the following traceback many times scrolling in firefox using the firefox HTML 5 viewer:
2015-05-13 14:26:39,648 error processing damage data: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server/source.py", line 1734, in encode_loop fn_and_args[0](*fn_and_args[1:]) File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1187, in make_data_packet_cb packet = self.make_data_packet(damage_time, process_damage_time, wid, image, coding, sequence, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1524, in make_data_packet ret = encoder(coding, image, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window_video_source.py", line 1245, in video_encode ret = self._video_encoder.compress_image(csc_image, quality, speed, options) File "xpra/codecs/enc_x264/encoder.pyx", line 520, in xpra.codecs.enc_x264.encoder.Encoder.compress_image (xpra/codecs/enc_x264/encoder.c:5861) AssertionError
EDIT: After actually using firefox after noticing this print it appears that painting is broken using h264. I will attach a screenshot.
after scrolling slightly on the fedora start page
Nope, still no luck. I've tried both trunk and v0.15.x.
Can you please post the exact commands that you've used (both client and server), the exact branch + revisions used for both (and maybe try trunk to see if the bug is present there or not), detailed steps (size of window, etc), xpra info
, and anything else that might be relevant.
As of r9358 (trunk), the AssertionError
message should include more information.
Using my 0.15.0 Fedora 21 build r9357 with the following start command:
xpra start :13 --no-daemon --bind-tcp=0.0.0.0:2200 --html=on --start-child=firefox --start-child=xterm --start-child=xterm
In addition I connected using Firefox and the h264 option. With normal fullscreen window
enabled.
After updating to the latest r9365 0.15.0 the traceback now prints:
2015-05-14 10:26:06,315 error processing damage data: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server/source.py", line 1734, in encode_loop fn_and_args[0](*fn_and_args[1:]) File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1187, in make_data_packet_cb packet = self.make_data_packet(damage_time, process_damage_time, wid, image, coding, sequence, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1524, in make_data_packet ret = encoder(coding, image, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window_video_source.py", line 1245, in video_encode ret = self._video_encoder.compress_image(csc_image, quality, speed, options) File "xpra/codecs/enc_x264/encoder.pyx", line 520, in xpra.codecs.enc_x264.encoder.Encoder.compress_image (xpra/codecs/enc_x264/encoder.c:5861) AssertionError 2015-05-14 10:26:06,370 error processing damage data: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server/source.py", line 1734, in encode_loop fn_and_args[0](*fn_and_args[1:]) File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1187, in make_data_packet_cb packet = self.make_data_packet(damage_time, process_damage_time, wid, image, coding, sequence, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1524, in make_data_packet ret = encoder(coding, image, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window_video_source.py", line 1245, in video_encode ret = self._video_encoder.compress_image(csc_image, quality, speed, options) File "xpra/codecs/enc_x264/encoder.pyx", line 520, in xpra.codecs.enc_x264.encoder.Encoder.compress_image (xpra/codecs/enc_x264/encoder.c:5861) AssertionError
I've just tried it, exactly as you describe, connecting with chrome 42.0.2311.152, no errors at all.
Please try with trunk so we can see the more detailed assert error message.
"normal fullscreen window" does not make any difference. Is it required to trigger the bug?
xpra info
, etc..
Updated to trunk and the encoding issues have disappeared. It appears to be confined to the 0.15.0 branch for me at the moment.
Lowering the priority as I am unable to reproduce, not for a lack of trying.
I think there must be something funny with your environment or build system.
Please provide more info on that, and try the latest beta builds I have just made to see if you can reproduce it with those. Please also provide xpra info
, etc.
Retested against an r9368 0.15.0 Fed 21 server from the beta repo and I am unable to reproduce the issue.
Looks like it's my build environment. I'll try poking it a bit and see what I come up with; but for now it looks like that issue has been resolved with your builds.
To be used sparingly and carefully, this is a script that I use when I want to wipe everything (ie: when switching branches during development):
sudo rm -fr \ /usr/bin/xpra* \ /usr/lib*/python*/site-packages/xpra* \ /usr/share/icons/xpra* \ /usr/share/man/man1/xpra* \ /usr/share/xpra* /usr/share/applications/xpra* \ /usr/lib/cups/backend/xpra*
And you may also want to run this from your xpra source directory:
rm -fr build ./setup.py clean
Connecting with a Win81 r9365 0.15.0 client with --encodings=h264
against your beta build I get the following traceback when highlighting text in Firefox:
2015-05-15 10:27:20,484 sound-source codec: MPEG-1 Layer 3 (MP3) Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 927, in expire_delayed_region self.may_send_delayed() File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1024, in may_send_delayed self.do_send_delayed() File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1036, in do_send_delayed self.send_delayed_regions(*delayed) File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1051, in send_delayed_regions self.do_send_delayed_regions(damage_time, window, regions, coding, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window_video_source.py", line 575, in do_send_delayed_regions return send_nonvideo(encoding=None) File "/usr/lib64/python2.7/site-packages/xpra/server/window_video_source.py", line 524, in send_nonvideo WindowSource.do_send_delayed_regions(self, damage_time, window, regions, encoding, options, exclude_region=exclude_region, get_best_encoding=get_best_encoding) File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1128, in do_send_delayed_regions self.process_damage_region(damage_time, window, region.x, region.y, region.width, region.height, actual_encoding, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window_video_source.py", line 610, in process_damage_region WindowSource.process_damage_region(self, damage_time, window, x, y, w, h, coding, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window_source.py", line 1166, in process_damage_region assert coding is not None AssertionError
Please post "xpra info" for a session showing this bug.
Just checking: is this still with firefox running through a chrome browser client or a native client directly? Please provide the full version numbers: Chrome, Firefox, etc..
The only way coding can be None here is if we fail to find a valid non-video encoding to use (and there must be a video region detected too at that point).
This code path will call get_best_nonvideo_encoding
to find one, and this can only return None if the non_video_encodings
list is empty, and it should not be:
is_cancelled(..)
after we get the coding, and before the assert - so this cannot be the cause here.
If this bug is reproducible, running the server with -d encoding
could help, it will log the non_video_encodings
- which is better than inferring it from "xpra info".
If you can reproduce this bug with a native 0.15.x client, please post the output of Encoding_Info.exe
, and try with the latest v0.14.x client too.
requested Xpra info with broken h264 encoder
Apologies for forgetting the Xpra info. I just attached it.
For clarification:
This is using a normal Xpra client launched from CMD using the following command: Xpra_cmd.exe attach tcp:10.0.32.137:2200 --encodings=h264
The client is a 0.15.X client that Smo built yesterday that has the revision number r9365. I am using Firefox running on the remote machine to get this error. The remote machine is running your latest Fedora 21 beta build, r9368.
Encoding_Info
outputs the following:
codecs and csc modules found: * PIL : library.zip\PIL\__init__.pyc * enc_vpx : xpra.codecs.vpx.encoder.pyd * dec_vpx : xpra.codecs.vpx.decoder.pyd * enc_x264 : xpra.codecs.enc_x264.encoder.pyd * enc_x265 : * nvenc3 : * nvenc4 : * nvenc5 : * csc_swscale : xpra.codecs.csc_swscale.colorspace_converter.pyd * csc_cython : xpra.codecs.csc_cython.colorspace_converter.pyd * csc_opencl : * dec_avcodec2 : xpra.codecs.dec_avcodec2.decoder.pyd * enc_webp : xpra.codecs.webp.encode.pyd * dec_webp : xpra.codecs.webp.decode.pyd codecs versions: * PIL : 2.2.1 * avcodec2 : 56.13.100 * cython : 0.3.0.20.2 * dec_webp : 0.4.1 * enc_webp : 0.4.1 * numpy : 1.8.1 * swscale : 3.1.101 * vpx : 1.4.0 * x264 : 142
Also of note:
If I launch the client using --encodings=h264,webp
, the issue goes away. It looks to only be a problem when forcing the client to only use h264.
In the future, please follow wiki/ReportingBugs, in particular the bit where I asked for the exact command lines used (also in comment:16). Knowing that, the bug is trivial to identify: I've moved to #863 since this has nothing to do with the html5 client.
You probably meant to use --encoding=h264
and not --encodings=h264
, see the man page for details. Saying In addition I connected using Firefox and the h264 option is NOT sufficient.
If the problems with the html5 client are resolved, please close this ticket.
Also, please be aware that your win32 builds have some seriously out of date libraries:
and probably others..
Everything within the scope of this ticket has been resolved.
Other issues, naturally, have been moved to other tickets.
Closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/854