Xpra: Ticket #797: Profile xpra and capture tests for regression

We can take a look at other things to educate ourselves, any result (positive or negative) should tell us more about the trade-offs we have decided to make and whether we should re-evaluate them (my bet: there is bound to be some that need another look).

Here are a few worth checking:

etc...

The important thing about running those tests is to run them again and again, after either narrowing down on the outliers or discarding them when we understand why they stick out.



Tue, 27 Jan 2015 23:27:02 GMT - Nick Centanni: owner changed


Tue, 27 Jan 2015 23:27:12 GMT - Nick Centanni: status changed


Wed, 28 Jan 2015 01:52:15 GMT - Antoine Martin: description changed; milestone set

(just re-formatting with wiki tags)


Thu, 05 Feb 2015 23:40:10 GMT - Nick Centanni:

I've attached the results of a 9-repetition test of v14 and v15. These data files can be extracted anywhere.

I've added a new utility in tests/xpra, called test_measure_perf_charts.py along with the necessary css and js files necessary to draw the charts in the resulting HTML file. These utility files were added in r8639.

Change tests/xpra/test_measure_perf_charts.py so it points to the directory where you placed the extracted data files.

The first version of this chart generator happens to already be configured for this data set (it has the correct prefix, params, and reps already configured), but normally you would need to change those to reflect the data set you're generating charts for.


Thu, 05 Feb 2015 23:41:23 GMT - Nick Centanni: attachment set

CSV files from a 9-repetition run of test_measure_perf comparing v14 and v15.


Fri, 08 May 2015 08:39:06 GMT - Antoine Martin:

This was done 3 months ago now, it would be worth running again, to see if anything has changed.


Mon, 15 Jun 2015 20:49:29 GMT - Nick Centanni: attachment set

Compares benchmark results of v15 done Feb-2015 with those done June-2015.


Mon, 15 Jun 2015 20:51:47 GMT - Nick Centanni:

Attached results of the new benchmark run on v15 Jun-2015, compared to the benchmark results taken for v15 Feb-2015.


Tue, 16 Jun 2015 09:55:06 GMT - Antoine Martin: status changed

Thanks nick! (FYI: please run with r9638 from now on: we want vp8 and vp9 tested, and "x264" is not a valid encoding name any more)

Things that stand out (one good news first, then mostly bad news):

Executive summary: we have serious quality control issues. We should have tackled those regressions during the 0.14 or 0.15 development cycles, not half way through the 0.16 release cycle. This data should be collected daily or weekly so we can identify regressions. And now this will need to be done anyway to identify the source of the regressions, more than doubling up the amount of work required to fix them.


Tue, 16 Jun 2015 14:49:56 GMT - Nick Centanni:

I've attached here all the CSV and log output from both the 15 (Feb) and 15_2 (June) tests. I checked the logs for crashes before preparing the data. There was a crash in 15_2 sequence 8, so I reran that sequence.

There were login timeouts in all of the Feb x11perf tests. But that test was not included in the charts.

The revision of the June v15 that was used for this test was: r9612.


Tue, 16 Jun 2015 14:50:42 GMT - Nick Centanni: attachment set

CSV and log files from the 15Feb_15Jun tests.


Mon, 06 Jul 2015 11:01:03 GMT - Antoine Martin:

Did you ever figure out where the variation came from? Once the data is reliable, it would be worth running again.


Tue, 04 Aug 2015 23:05:07 GMT - Nick Centanni:

In addition to the first two comparisons r8585 vs r9612 (all tests) and r8585 vs r9612 (h264 glx tests only), I ran each of these 4 cases an additional 3 times to compare the deviation between tests. This can be seen in the attached archive.

Untar the archive and view index.html, which contains explanations of each chart in the set.


Tue, 04 Aug 2015 23:06:07 GMT - Nick Centanni: attachment set

Collection of several charts visualizing 16 repetitions of the benchmark tests.


Thu, 06 Aug 2015 13:08:14 GMT - Antoine Martin:

@nick: can you give us a quick "executive summary" of what you did and why, and your initial conclusions?

I've had a look and noticed:

Am I reading this right?


Thu, 06 Aug 2015 22:20:20 GMT - Nick Centanni:

@antoine: since we were getting contradictory results between the comparison done of v15 and v16 in June -- when all tests were run -- and the results we got between the same revisions in July -- when only h264 glx tests were run -- I wanted to do some sanity tests just to verify that the test results are reliable.

Specifically:

About the graphs: The graphs to look at are the last two (on index.html). They combine all repetitions of the tests. I couldn't fit legends on the graphs (let alone both apps), so here's a description:

Observations:

v15 vs v16:


Wed, 04 Nov 2015 07:33:26 GMT - Antoine Martin:

Stumbled upon this package which could be useful for visualizing datasets: Animator5D.


Wed, 16 Mar 2016 07:04:16 GMT - Antoine Martin: owner, milestone changed

I believe smo is going to be running those tests again from now on.


Tue, 12 Jul 2016 16:52:22 GMT - Antoine Martin: milestone changed

Milestone renamed


Thu, 13 Oct 2016 23:04:56 GMT - Smo: owner changed

I am indeed running the tests again on fedora 24.

I've run into an issue running the tests on xpra 1.0 from winswitch-beta

Traceback (most recent call last):
  File "/home/xpra/tests/xpra/test_measure_perf.py", line 81, in <module>
    XPRA_VERSION_NO = [int(x) for x in XPRA_VERSION.split(".")]
ValueError: invalid literal for int() with base 10: '0-r14149'

I will attach my data from the tests to this ticket along with full logs.


Fri, 14 Oct 2016 01:09:03 GMT - Antoine Martin: owner changed

Untested: I believe r14150 fixes this.


Fri, 14 Oct 2016 01:22:55 GMT - Smo: attachment set

0.16.3 performance logs from fedora 24


Fri, 14 Oct 2016 01:23:26 GMT - Smo: attachment set

0.17.5 performance logs from fedora 24


Fri, 14 Oct 2016 01:26:28 GMT - Smo:

Fix works running the tests on 1.0 beta from winswitch-beta repo now will post the results when they are done.


Thu, 20 Oct 2016 23:29:23 GMT - Smo:

I see this traceback running the tests with the 1.0 beta client/server

raceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/client/gtk_base/gtk_tray_menu_base.py", line 404, in bell_toggled
DPI set to 96 x 96
    self.client.send_bell_enabled()
  File "/usr/lib64/python2.7/site-packages/xpra/client/ui_client_base.py", line 2626, in send_bell_enabled
    assert self.client_supports_bell, "cannot toggle bell: the feature is disabled by the client"
AssertionError: cannot toggle bell: the feature is disabled by the client

Thu, 20 Oct 2016 23:32:10 GMT - Smo: attachment set


Thu, 20 Oct 2016 23:35:42 GMT - Smo:

I have attached a log of the issue i'm currently having running the tests for 1.0 beta.

It seems to me that the server isn't shutting down properly after the first test run.

Here is a list of the running processes at the end of that log.

[xpra@xpratb01 ~]$ ps x -www
  PID TTY      STAT   TIME COMMAND
 1250 ?        Ss     0:00 /usr/lib/systemd/systemd --user
 1252 ?        S      0:00 (sd-pam)
 1257 ?        S      0:00 sshd: xpra@pts/1
 1258 pts/1    Ss     0:00 -bash
 1279 pts/1    S+     0:00 /bin/bash /home/xpra/bin/runtest
 1286 pts/1    S+     0:00 tee /home/xpra/data/new-1.0-1.log
 1307 pts/1    Sl+    1:48 /usr/bin/python2 /usr/bin/xpra --bind-tcp=0.0.0.0:10000 --password-file=./test-password.txt --auth=file --tcp-auth=file start :10 --daemon=no --pulseaudio=no --notifications=no
 1308 pts/1    Sl+    0:00 /usr/bin/pkttyagent --notify-fd 5 --fallback
 1315 ?        Ssl    0:45 /usr/libexec/Xorg -noreset -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth /home/xpra/.Xauthority -logfile /run/user/1001/xpra/Xorg.:10.log -configdir /home/xpra/.xpra/xorg.conf.d -config /etc/xpra/xorg.conf :10
 1326 ?        Ssl    0:00 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --session
 1361 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
 1700 ?        S      0:00 sshd: xpra@pts/2
 1701 pts/2    Ss     0:00 -bash
 1735 pts/2    R+     0:00 ps x -www

Fri, 21 Oct 2016 04:09:40 GMT - Antoine Martin:

I'm not sure how to reproduce the bug in comment:19, r14235 fixes the symptoms only.. As for the server not shutting down properly, maybe we want to run with "systemd-run" turned off for the tests? Does that help?


Thu, 27 Oct 2016 21:22:40 GMT - Smo:

Changing

systemd-run = no in /etc/xpra/conf.d/60_server.conf allowed me to continue on with the tests on fedora 24 with 1.0 beta

I will post the data here shortly then I will take a look at logs.


Thu, 27 Oct 2016 21:59:56 GMT - Smo: attachment set


Thu, 27 Oct 2016 22:04:16 GMT - Smo:

lots of errors from vp8 in these logs

Error during encoding:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/source.py", line 2185, in encode_loop
    fn_and_args[1](*fn_and_args[2:])
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1448, in make_data_packet_cb
    packet = self.make_data_packet(damage_time, process_damage_time, image, coding, sequence, options, flush)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1794, in make_data_packet
    ret = encoder(coding, image, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 1467, in video_encode
    return self.do_video_encode(encoding, image, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 1568, in do_video_encode
    ret = ve.compress_image(csc_image, quality, speed, options)
  File "xpra/codecs/vpx/encoder.pyx", line 584, in xpra.codecs.vpx.encoder.Encoder.compress_image (xpra/codecs/vpx/encoder.c:8327)
AssertionError

Thu, 27 Oct 2016 22:09:53 GMT - Smo:

saw this error as well when the server was shutting down

got signal SIGTERM, exiting
client has requested disconnection: exit on signal SIGTERM
Disconnecting client 127.0.0.1:54674:
 client request
Warning: no matching argb function: cannot convert BGRX to one of: []
Warning: cannot convert BGRX to one of: []
error processing encode queue at index 0
item=(504, 504, 1477598147.752195, 1477598147.792868, XShmImageWrapper(BGRX: 1, 1, 504, 504), 'rgb24', 6951, {}, 0)
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 823, in encode_from_queue
    self.make_data_packet_cb(*item)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1448, in make_data_packet_cb
    packet = self.make_data_packet(damage_time, process_damage_time, image, coding, sequence, options, flush)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1794, in make_data_packet
    ret = encoder(coding, image, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1884, in rgb_encode
    self.rgb_zlib, self.rgb_lz4, self.rgb_lzo)
  File "/usr/lib64/python2.7/site-packages/xpra/server/picture_encode.py", line 87, in rgb_encode
    raise Exception("cannot find compatible rgb format to use for %s! (supported: %s)" % (pixel_format, rgb_formats))
Exception: cannot find compatible rgb format to use for BGRX! (supported: [])
xpra client 1 disconnected.

Fri, 28 Oct 2016 04:08:06 GMT - Antoine Martin:

The vp8 one is real, saw it before so I added a better error message in r14239.

The other one looks harmless, is fixed in r14305, but inspecting the code I found more issues: see ticket:835#comment:34


Tue, 01 Nov 2016 22:06:09 GMT - Smo: attachment set


Tue, 01 Nov 2016 22:06:25 GMT - Smo: attachment set


Tue, 01 Nov 2016 22:14:27 GMT - Smo:

In the latest 1.0 tests I see these tracebacks

Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/source.py", line 2185, in encode_loop
    fn_and_args[1](*fn_and_args[2:])
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1440, in make_data_packet_cb
    packet = self.make_data_packet(damage_time, process_damage_time, image, coding, sequence, options, flush)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1786, in make_data_packet
    ret = encoder(coding, image, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 1512, in video_encode
    return self.do_video_encode(encoding, image, options)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 1614, in do_video_encode
    ret = ve.compress_image(csc_image, quality, speed, options)
  File "xpra/codecs/vpx/encoder.pyx", line 584, in xpra.codecs.vpx.encoder.Encoder.compress_image (xpra/codecs/vpx/encoder.c:9075)
AssertionError: invalid image width 1240, expected 826

Wed, 02 Nov 2016 02:34:03 GMT - Antoine Martin:

There's a very good chance that the "invalid image width" is fixed by r14365.


Thu, 03 Nov 2016 23:45:38 GMT - Smo: attachment set


Thu, 03 Nov 2016 23:45:53 GMT - Smo: attachment set


Thu, 03 Nov 2016 23:49:44 GMT - Smo:

In 1.0-r14384 logs attached the vpx issue seems to be gone.

I did notice some errors like these

/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py:803: Warning: Source ID 452 was not found when attempting to remove it
  self.source_remove(eqt)
/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py:803: Warning: Source ID 484 was not found when attempting to remove it
  self.source_remove(eqt)

Also mplayer test seems to be failing I will have to fix this or disable it.


Thu, 03 Nov 2016 23:55:41 GMT - Smo:

Looking over 0.17.6-2 logs I notice there is sometimes this issue when shutting down.

2016-11-01 18:04:16,489 New tcp connection received from 127.0.0.1:54160
2016-11-01 18:04:26,114 Authentication required by password file authenticator module
2016-11-01 18:04:26,114  sending challenge for 'xpra' using hmac digest
2016-11-01 18:04:28,337 connection timedout: Protocol(tcp socket: 127.0.0.1:10000 <- 127.0.0.1:54160)
got signal SIGTERM, exiting
Traceback (most recent call last):
  File "/home/xpra/tests/xpra/test_measure_perf.py", line 510, in with_server
    data.update(measure_client(server_pid, name, client_cmd, get_stats_cb))
  File "/home/xpra/tests/xpra/test_measure_perf.py", line 361, in measure_client
    initial_stats = get_stats_cb()
  File "/home/xpra/tests/xpra/test_measure_perf.py", line 588, in xpra_get_stats
    out = getoutput(info_cmd)
  File "/home/xpra/tests/xpra/test_measure_perf.py", line 56, in getoutput
    raise Exception("command '%s' returned error code %s, out=%s, err=%s" % (cmd, code, out, err))
Exception: command '['/usr/bin/xpra', 'info', 'tcp:127.0.0.1:10000', '--password-file=./test-password.txt', '--auth=file', '--tcp-auth=file']' returned error code 7, out=server failure: disconnected before the session could be established
server requested disconnect: login timeout
, err=None
2016-11-01 18:04:29,497 Connection lost
2016-11-01 18:04:29,502 xpra client disconnected.
2016-11-01 18:04:29,504 processed info request from None in 8ms
2016-11-01 18:04:30,472 got signal SIGTERM, exiting
2016-11-01 18:04:30,475 closing tcp socket 0.0.0.0:10000
2016-11-01 18:04:30,475 removing socket /home/xpra/.xpra/xpratb01-10
2016-11-01 18:04:30,477 killing xvfb with pid 21711
(II) Server terminated successfully (0). Closing log file.

Probably cause by it closing while the client is trying to request info.


Thu, 03 Nov 2016 23:57:14 GMT - Smo:

This test fails as well because it has changed locations

Traceback (most recent call last):
  File "/home/xpra/tests/xpra/test_measure_perf.py", line 479, in with_server
    assert code is None, "test command %s failed to start: exit code is %s" % (cmd, code)
AssertionError: test command ['/usr/bin/vglrun', '--', '/usr/bin/xterm', '-geometry', '160x60', '-e', 'PYTHONPATH=`pwd` ./tests/xpra/simulate_console_user.py'] failed to start: exit code is 0

I'll make the necessary changes to my config but this should be reflected in the default one.


Fri, 04 Nov 2016 00:12:45 GMT - Smo:

Example of why mplayer is failing for the audio test

Traceback (most recent call last):
  File "/home/xpra/tests/xpra/test_measure_perf.py", line 479, in with_server
    assert code is None, "test command %s failed to start: exit code is %s" % (cmd, code)
AssertionError: test command /usr/bin/vglrun -- while true; do /usr/bin/mplayer ./test.mp3; done failed to start: exit code is 1

When we run this command by hand we get a weird error

[xpra@xpratb01 ~]$ /usr/bin/vglrun -- while true; do /usr/bin/mplayer ./test.mp3; done
-bash: syntax error near unexpected token `do'

Suggestion we just use mplayer -loop 0 ./test.mp3 instead of the while loop and this should be good i'll make changes in my test config but defaults should be updated


Fri, 04 Nov 2016 05:33:35 GMT - Smo: attachment set


Tue, 08 Nov 2016 02:09:37 GMT - Smo: attachment set


Thu, 17 Nov 2016 01:39:42 GMT - Smo: attachment set


Thu, 17 Nov 2016 01:39:55 GMT - Smo: attachment set


Wed, 23 Nov 2016 01:09:22 GMT - Smo: attachment set


Wed, 23 Nov 2016 01:09:41 GMT - Smo: attachment set


Wed, 23 Nov 2016 01:15:25 GMT - Smo:

I sometimes see this traceback when looking at the logs usually when running glxgears.

Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/server_core.py", line 1156, in in_thread
    info = self.get_info(proto, *args)
  File "/usr/lib64/python2.7/site-packages/xpra/server/server_base.py", line 1959, in get_info
    dgi = self.do_get_info(proto, sources, wids)
  File "/usr/lib64/python2.7/site-packages/xpra/x11/server.py", line 274, in do_get_info
    info = X11ServerBase.do_get_info(self, proto, server_sources, window_ids)
  File "/usr/lib64/python2.7/site-packages/xpra/x11/x11_server_base.py", line 249, in do_get_info
    info = GTKServerBase.do_get_info(self, proto, server_sources, window_ids)
  File "/usr/lib64/python2.7/site-packages/xpra/server/gtk_server_base.py", line 117, in do_get_info
    info = ServerBase.do_get_info(self, proto, *args)
  File "/usr/lib64/python2.7/site-packages/xpra/server/server_base.py", line 2095, in do_get_info
    info.update(ss.get_window_info(window_ids))
  File "/usr/lib64/python2.7/site-packages/xpra/server/source.py", line 1586, in get_window_info
    winfo[wid] = ws.get_info()
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 169, in get_info
    info = WindowSource.get_info(self)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 398, in get_info
    lde = [x for x in self.statistics.last_damage_events if x[0]>=cutoff]
RuntimeError: deque mutated during iteration

Mon, 26 Dec 2016 09:27:42 GMT - Antoine Martin:

The stacktrace from comment:32 is fixed in r14615. Have you made the other changes yet?


Tue, 07 Feb 2017 19:28:34 GMT - Smo:

Had to make some modifications to the test script some of it was just for debugging but it doesn't seem to hurt anything. Now I have the problem with the 2nd stop command not being called by the full path and not using Shell=true means the commands need their full path. This way of killing the Xorg process doesn't work in newer versions anyways. I think stopping the xpra server properly is a better way and should hopefully shut down cleanly.

Also needed the password file for newer versions. I will attach my logs from 1.0.2 before I review them and also see if I can start the tests from 2.0.0 from the beta repo

Index: xpra/test_measure_perf.py
===================================================================
--- xpra/test_measure_perf.py	(revision 14995)
+++ xpra/test_measure_perf.py	(working copy)
@@ -81,7 +81,7 @@
 XPRA_VERSION = XPRA_VERSION.split("-")[0]
 XPRA_VERSION_NO = [int(x) for x in XPRA_VERSION.split(".")]
 XPRA_SERVER_STOP_COMMANDS = [
-                             [XPRA_BIN, "stop", ":%s" % config.DISPLAY_NO],
+                             [XPRA_BIN, "--password-file=./test-password.txt",  "stop", ":%s" % config.DISPLAY_NO],
                              "ps -ef | grep -i [X]org-for-Xpra-:%s | awk '{print $2}' | xargs kill" % config.DISPLAY_NO
                              ]
 XPRA_INFO_COMMAND = [XPRA_BIN, "info", "tcp:%s:%s" % (config.IP, config.PORT)]
@@ -524,8 +524,11 @@
                     for s in stop_server_commands:
                         print("stopping server with: %s" % (s))
                         try:
-                            stop_process = subprocess.Popen(s, stdin=None, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
+                            stop_process = subprocess.Popen(s, stdin=None, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
                             stop_process.wait()
+                            output, error = stop_process.communicate()
+                            if output:
+                                print("output: %s" % output)
                         except Exception as e:
                             print("error: %s" % e)
                     try_to_kill(server_process, 5)

Tue, 07 Feb 2017 19:29:33 GMT - Smo: attachment set


Tue, 07 Feb 2017 19:31:58 GMT - Smo:

Here is an example of one of the stop commands not working now.

stopping server with: ['/usr/bin/xpra', '--password-file=./test-password.txt', 'stop', ':10']
output: server requested disconnect: server shutdown
xpra at :10 has exited.
stopping server with: ps -ef | grep -i [X]org-for-Xpra-:10 | awk '{print $2}' | xargs kill
error: [Errno 2] No such file or directory

Since there is no shell we'd have to call all these commands by their full path.


Thu, 09 Feb 2017 05:33:58 GMT - Antoine Martin:

Unix sockets shouldn't require authentication, r15021 tries to make sure of that. If that doesn't help, we could just rip out all the password stuff - we have good unit test coverage for that already.

The reason why we try to kill Xorg is that if one was left behind, this could cause later tests to fail. Why do we have to turn shell=True off? We can turn the "xpra stop" command into a plain string if that helps - I'd rather keep the kill command in there.


Fri, 10 Feb 2017 19:24:09 GMT - Smo:

That fix works for the password issue. We can leave shell=True if we turn the command into a string that works.


Mon, 06 Mar 2017 22:54:57 GMT - Smo: attachment set


Mon, 06 Mar 2017 22:57:25 GMT - Smo:

I've attached a set of logs and data from 2.0-0.20170302r15219-1 on fedora 24

There were several crashes and one of the machines froze completely so there is no csv for that one.

I will check over the logs for errors. This is the first time I've been able to run through some tests on 2.0.


Mon, 06 Mar 2017 23:02:07 GMT - Smo:

Traceback (most recent call last):
  File "/home/xpra/tests/xpra/test_measure_perf.py", line 475, in with_server
    assert code is None, "test command %s failed to start: exit code is %s" % (cmd, code)
AssertionError: test command ['/usr/bin/vglrun', '--', '/usr/bin/xterm', '-geometry', '160x60', '-e', "'PYTHONPATH=`pwd` ./tests/xpra/test_apps/simulate_console_user.py'"] failed to start: exit code is 0

This test seems to be failing to start. I'll have to try the test manually


Mon, 06 Mar 2017 23:29:15 GMT - Smo:

I've seen at least one instance of this in the logs not sure what it is might be worth noting

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
python2: xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

Tue, 07 Mar 2017 01:30:16 GMT - Antoine Martin:

For the error in comment:40, see #1456


Wed, 08 Mar 2017 22:30:32 GMT - Smo:

Great this is starting to look better. It looks like there is an issue during one of the VLC tests and x264.

2017-03-08 13:29:21,430 item=(0, 791, 1489008561.391492, 1489008561.424384, XImageWrapper(BGRX: 0, 790, 1280, 1), 'rgb24', 4524, {}, 1)
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 877, in encode_from_queue
    self.make_data_packet_cb(*item)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1488, in make_data_packet_cb
    packet = self.make_data_packet(damage_time, process_damage_time, image, coding, sequence, options, flush)
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1822, in make_data_packet
    image.set_pixels(xored)
  File "xpra/x11/bindings/ximage.pyx", line 413, in xpra.x11.bindings.ximage.XImageWrapper.set_pixels (xpra/x11/bindings/ximage.c:5045)
AssertionError

I've checked the logs from and it appears in more than one of the runs.


Wed, 08 Mar 2017 22:32:06 GMT - Smo: attachment set


Thu, 09 Mar 2017 04:32:16 GMT - Antoine Martin:

The bug in comment:42 should be fixed in r15234.

It was happening when we use delta encoding (#756) with a non-scroll region as part of the scroll encoding. (#1232)


Fri, 10 Mar 2017 06:28:01 GMT - Smo: attachment set


Fri, 10 Mar 2017 06:28:19 GMT - Smo: attachment set


Fri, 10 Mar 2017 06:30:13 GMT - Smo:

Attached some data from tests done with 1.0.3 from the stable repo.

Also used test_measure_perf_charts to generate the chart that is attached as well 103v20

Had to change directories and filenames from using '-' to '_' or the javascript fails.


Fri, 10 Mar 2017 06:31:17 GMT - Smo:

There are a few values that doesn't seem to be working in those charts and i'm also missing the network info since I didn't enable the use of ipchains in the performance tests.


Fri, 10 Mar 2017 07:29:53 GMT - Antoine Martin:

Noteworthy graphs:

We should update the test code to also run in "auto" mode - which is now the default.


Mon, 13 Mar 2017 17:06:25 GMT - Smo: attachment set


Mon, 13 Mar 2017 17:08:32 GMT - Smo:

I will add another set of logs from 2.0 here soon I'm just waiting on one machine to complete. The machine locked up on the nexuiz test last time I think.

I'll also compare those 2 sets of results. They should have the network info as I enabled the firewall rules to track them.


Tue, 14 Mar 2017 00:25:28 GMT - Smo: attachment set


Fri, 14 Jul 2017 16:08:38 GMT - Antoine Martin:

No data - can I close this and assume that the code is 100% perfect? ;)


Sun, 17 Sep 2017 05:52:57 GMT - Antoine Martin: status changed; resolution set

Hopefully maxmylyn can follow up in a different ticket.


Sat, 23 Jan 2021 05:06:15 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/797