xpra icon
Bug tracker and wiki

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#854 closed defect (fixed)

HTML 5 client crash by scrolling in Firefox

Reported by: J. Max Mena Owned by: J. Max Mena
Priority: critical Milestone: 0.15
Component: html5 Version: 0.15.x
Keywords: Cc:

Description (last modified by Antoine Martin)

Using Windows 8.1 x64 and Firefox 37.0.2 against a Fedora 21 0.15.0 r9285 server:

  • Connecting and browsing websites in Firefox(running on the remote machine) works more or less fine
    • using h264
  • Attempting to scroll using the mouse causes an immediate disconnect and the following traceback on the server:
    • Scrolling in any open application
      • using xterm and firefox at the moment
        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
        

Attachments (4)

bencoder-python2-refix.patch (6.5 KB) - added by Antoine Martin 2 years ago.
partial revert which at least gets python2 working again..
bencoder-python2-refix-v2.patch (5.8 KB) - added by Antoine Martin 2 years ago.
all but one test fails..
xpra 15 ticket 854 r9537 broken paint.png (182.1 KB) - added by J. Max Mena 2 years ago.
after scrolling slightly on the fedora start page
854xprainfo.txt (123.5 KB) - added by J. Max Mena 2 years ago.
requested Xpra info with broken h264 encoder

Download all attachments as: .zip

Change History (31)

comment:1 Changed 2 years ago by Antoine Martin

Description: modified (diff)
Milestone: 0.160.15
Priority: majorblocker

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

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

comment:2 Changed 2 years ago by Antoine Martin

(r9286 avoids the bottom stacktrace - backport to v0.15.x in r9287)

comment:3 Changed 2 years ago by J. Max Mena

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

Last edited 2 years ago by J. Max Mena (previous) (diff)

comment:4 Changed 2 years ago by Antoine Martin

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?

comment:5 Changed 2 years ago by Josh

@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?

comment:6 Changed 2 years ago by Antoine Martin

Owner: changed from Josh to J. Max Mena

Backport to v0.15.x in r9293. Works-for-me.

@maxmylyn: can you still break it?

comment:7 Changed 2 years ago by J. Max Mena

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


  • Also(still using trunk), simply typing a '-' into an Xterm (to do 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

Last edited 2 years ago by J. Max Mena (previous) (diff)

comment:8 Changed 2 years ago by Antoine Martin

Owner: changed from J. Max Mena to Antoine Martin
Status: newassigned

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.

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

comment:9 Changed 2 years ago by Antoine Martin

r9304 adds a test for this unicode pita.

Changed 2 years ago by Antoine Martin

partial revert which at least gets python2 working again..

Changed 2 years ago by Antoine Martin

all but one test fails..

comment:10 Changed 2 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
Status: assignednew

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

comment:11 Changed 2 years ago by J. Max Mena

Upped to 9329 0.15.0:

  • My keyboard randomly broke and I could no longer type into Firefox(using Firefox) with 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.
  • Important note: I am still unable to reproduce the keyboard issue; it was most likely a one-time-fluke.

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

  • Interestingly it doesn't kick me, and the session continues, just flooding the CMD window with prints, unlike the 0.15.0 build which immediately disconnects me.

If you think this new issue is unrelated to the work on this one, then I can open a separate ticket.

comment:12 Changed 2 years ago by Antoine Martin

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)

  • My keyboard randomly broke... This ones sounds like an html client issue? I'll need some debug log or steps to reproduce for this one, there is nothing related to the keyboard in that log sample
  • 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?

comment:13 Changed 2 years ago by J. Max Mena

Keyboard randomly broke


  • I will look for some repro steps today to see if I can find any. I only ran into it after trying to get NumLock? enabled.
    • I will file a ticket about NumLock? being non-functional in Win/OSX, right after I manage to get an HTML5 compatible browser on my Cent6.4 system to test there.


ValueError? ..... Steps to reproduce would be welcome


Found a semi-reliable repro using my trunk build:

  • Start a trunk server (using Fed20 Trunk)
  • Connect HTML5 client with normal fullscreen windows enabled
  • Connect a normal Xpra client (was using Win8.1 r9202, will try others) to 'steal' your session
    • Assuming it doesn't just disconnect you, you should see that traceback on the server

EDIT:

  • Attempting these steps with 0.15.0 will just disconnect the regular client and give a traceback on the server.


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.

Last edited 2 years ago by J. Max Mena (previous) (diff)

comment:14 Changed 2 years ago by Antoine Martin

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)

comment:15 Changed 2 years ago by J. Max Mena

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.

Last edited 2 years ago by J. Max Mena (previous) (diff)

Changed 2 years ago by J. Max Mena

after scrolling slightly on the fedora start page

comment:16 Changed 2 years ago by Antoine Martin

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.

comment:17 Changed 2 years ago by J. Max Mena

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

comment:18 Changed 2 years ago by Antoine Martin

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

comment:19 Changed 2 years ago by J. Max Mena

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.

comment:20 Changed 2 years ago by Antoine Martin

Priority: blockercritical

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.

comment:21 Changed 2 years ago by J. Max Mena

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.

comment:22 Changed 2 years ago by Antoine Martin

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
Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:23 Changed 2 years ago by J. Max Mena

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
Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:24 Changed 2 years ago by Antoine Martin

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:

  • we should always support at least rgb24 as fallback (and the html5 client also has jpeg and png) - r9384 allows us to use rgb32 as fallback too since the html5 client doesn't have rgb24. (will backport)
  • during window source cleanup it can be empty (ie: usually when the window gets destroyed), but we check the cancellation list via 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.

Changed 2 years ago by J. Max Mena

Attachment: 854xprainfo.txt added

requested Xpra info with broken h264 encoder

comment:25 Changed 2 years ago by J. Max Mena

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.

comment:26 Changed 2 years ago by Antoine Martin

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:

  • PIL (2.8.1) - which may cause memory leaks, causes webp to get disabled, etc..
  • webp (0.4.3)
  • numpy (1.9)

and probably others..

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

comment:27 Changed 2 years ago by J. Max Mena

Resolution: fixed
Status: newclosed

Everything within the scope of this ticket has been resolved.

Other issues, naturally, have been moved to other tickets.

Closing.

Note: See TracTickets for help on using tickets.