300% cpu utilization when detached with no windows opened #2714

totaam · 2020-04-07T10:12:46Z

Issue migrated from trac ticket # 2714

component: server | priority: blocker | resolution: fixed

2020-04-07 10:12:46: marcelo created the issue

Hi thanks for such a great product.
I am having trouble with xpra after it is opened more than a few days.
The xpra process starts consuming a huge amount of CPU (100% for 3 CPUS). This continues when I close all the windows and even when i detach the client

totaam · 2020-04-07T10:14:58Z

Please see ReportingBugs wiki, at the very least we need:

OS used
versions
xpra info
etc.

totaam · 2020-04-07T10:16:25Z

2020-04-07 10:16:25: marcelo commented

Some more info.
From top:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
25076 marcelo   20   0 2914840 1.145g 123608 S 300.3  8.9   3900:14 xpra

xpra version:

$ xpra --version
xpra v3.0.7-25627

Linux version (ubuntu 18.04):

$ uname -a
Linux marcelo-vm 5.3.0-42-generic #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Installation:

	# add GPG key
	wget -q https://xpra.org/gpg.asc -O- | sudo apt-key add -
	# add XPRA repository
	sudo add-apt-repository "deb https://xpra.org/ bionic main"
	# install XPRA package
	sudo apt-get install xpra

totaam · 2020-04-07T10:17:32Z

2020-04-07 10:17:32: marcelo uploaded file `1.log` (48.1 KiB)

totaam · 2020-04-07T10:19:01Z

2020-04-07 10:19:01: marcelo uploaded file `xpra.info` (180.8 KiB)

totaam · 2020-04-07T10:21:18Z

2020-04-07 10:21:18: marcelo uploaded file `xpra.showconfig` (10.3 KiB)

totaam · 2020-04-07T10:23:04Z

2020-04-07 10:23:04: marcelo commented

Information about the client (even though it does not need to be connected):
3.0.7

Python 3.8, 64bit

revision 25627
built on Win7Pro64-PC by Win7 Pro 64
2020-03-13 17:00

using Cython 0.29.15
gcc (Rev2, Built by MSYS2 project) 9.2.0

totaam · 2020-04-07T10:52:49Z

compressors           (used)   = 'zlib'                            <class 'list'>
compressors          (default) = 'lz4', 'lzo', 'zlib', 'brotli'    <class 'list'>

Ouch! Why did you change this?
That's a terrible idea. Don't use zlib, ever!
As per your server log:

 Warning: zlib is the only compressor enabled
 install and enable lz4 support for better performance

encodings             (used)   = 'rgb', 'rgb24', 'rgb32'           <class 'list'>
quality               (used)   = 100                               <class 'int'>
speed                 (used)   = 100                               <class 'int'>

OK, I hope that you have bandwidth to spare for those settings!
If you're going to use these settings, I suggest you also add --video-encoders=none and --csc-modules=none. This will save RAM and speedup initialization.

commands.command=('gnome-terminal',)
commands.dead=True
commands.returncode=0

So you had a gnome-terminal running, but then it terminated.

What else is running in this session?

When you captured xpra info, there was nothing:

state.windows=0

Can you capture xpra info when the problem is happening?
Please also try sending a SIGUSR1 and SIGUSR2 signal to the server, these should show up in the log.
Can you reproduce the problem with an open source application I can test and reproduce with?
Have you tried disabling the speaker and clipboard options?

Another thing worth trying is to enable full server debug logging for just a few seconds, ie for $DISPLAY :1:

xpra control :1 debug enable all
sleep 10
xpra control :1 debug disable all

Then the server log file should tell us what the server is spending its CPU time on.

300% is very suspicious: most of the server code is single threaded, so it should not be using more than 100% unless you're using a video encoder... (but your settings don't allow that)

totaam · 2020-04-08T08:02:16Z

compressors           (used)   = 'zlib'                            <class 'list'>
compressors          (default) = 'lz4', 'lzo', 'zlib', 'brotli'    <class 'list'>
Ouch! Why did you change this?
That's a terrible idea. Don't use zlib, ever!
I wanted to disable compression entirely, precisely because i was aiming for minimal cpu utilization. But when i disabled everything it seems i failed to connect from my windows client, I could not find an option in the GUI to allow no compression, so i re enabled zlib since i saw in the logs this was required by the client. I will try to change this. Not sure this is related to the problem though, because i am able to work for a day or two perfectly normal till the problem arises.
As per your server log:
Warning: zlib is the only compressor enabled
 install and enable lz4 support for better performance
encodings             (used)   = 'rgb', 'rgb24', 'rgb32'           <class 'list'>
quality               (used)   = 100                               <class 'int'>
speed                 (used)   = 100                               <class 'int'>
OK, I hope that you have bandwidth to spare for those settings!
If you're going to use these settings, I suggest you also add --video-encoders=none and --csc-modules=none. This will save RAM and speedup initialization.
I am connecting from my windows machine to a virtual machine in ubuntu, its everything happening in a virtual network so I think i should not have bandwidth problems. Will try your recommendation to save memory.

commands.command=('gnome-terminal',)
commands.dead=True
commands.returncode=0
So you had a gnome-terminal running, but then it terminated.

What else is running in this session?
At the moment this all began I was running gnome-terminal and some other UI windows which i think are based on java, one of them is the eclipse IDE. Also a firefox window, i suspect the firefox window is the one causing more problems for xpra, I noticed sometimes xpra failed to draw the full firefox windows after resizing (maximizing), so i had to disconnect and reconnect to the server. But in any case the problem does not happen inmeddiately when i open all those windows, its able to handle all of it with a few percentage points of cpu utilization. The cpu usage starts one or two days after the session is open and maybe its independent on the amount of current windows.
When you captured xpra info, there was nothing:
state.windows=0
Can you capture xpra info when the problem is happening?
Please also try sending a SIGUSR1 and SIGUSR2 signal to the server, these should show up in the log.
The reason for having no windows opened is that I closed all the windows on purpose to see if the CPU utilization goes away, i also detached the client. But the xpra process stays at 300%.
xpra info was taken when the problem is still happening, I will try take xpra info when the applications are still open, also take SIGUSR1 and SIGUSER2. Right now i restarted the machine so i will attach it on the next time this happens. Do you want me to retain the ticket till this reproduces?

Can you reproduce the problem with an open source application I can test and reproduce with?
I will try. Since the problem requires a few days of waiting this is a little bit difficult.

Have you tried disabling the speaker and clipboard options?
I will try.
Another thing worth trying is to enable full server debug logging for just a few seconds, ie for $DISPLAY :1:
xpra control :1 debug enable all
sleep 10
xpra control :1 debug disable all
Then the server log file should tell us what the server is spending its CPU time on.
Ok.

totaam · 2020-04-08T08:16:11Z

2020-04-08 08:16:11: antoine commented

At the moment this all began I was running gnome-terminal and some other UI windows which i think are based on java, one of them is the eclipse IDE.
Eclipse is known to cause a few problems (clipboard is one: #2715)
Also a firefox window, i suspect the firefox window is the one causing more problems for xpra, I noticed sometimes xpra failed to draw the full firefox windows after resizing (maximizing), so i had to disconnect and reconnect to the server.
That's a very drastic solution, refreshing or re-initializing the window from the system tray would probably do just as well.

Do you want me to retain the ticket till this reproduces?
Yes please.

The reason for having no windows opened is that I closed all the windows on purpose to see if the CPU utilization goes away, i also detached the client. But the xpra process stays at 300%.
If SIGUSR1 / SIGUSR2 don't work (can happen if the server is in a bad state), then you may have to attach gdb and get a backtrace showing what the server is doing.
gdb
$ att $THEXPRASERVERPID
$ bt

totaam · 2020-04-12T09:47:13Z

2020-04-12 09:47:13: marcelo commented

It took a while and I cannot be sure its an exact reproduction.
This time I was working with firefox open scrolling up and down a JIRA webpage, the main activities were scrolling clicking on links and copy pasting, the same set of programs were open in the background as last time: gnome-terminal, eclipse UI and I forgot to mention last time but sometimes i had a program that uses openGL called SUMO (but was not running at the time of the reproduction).
Suddenly i noticed firefox was not responding correctly, the mouse pointer would stay as the hand symbol no matter how much i move the mouse (as if i was hovering over a link) and the program was not responding correctly to mouse clicks, still responding correctly to keyboard presses. I tried to reinit and refresh the windows butit did not help much; disconnecting the xpra client and reconnected fixed it. Still I also noticed the CPU fan working non stop and thought this might be a reproduction of the bug.
Another detail which might be relevant: I was sharing my screen with zoom (running on the client operating system, ie. windows), but the problem persists after zoom is closed.
This time the CPU usage is 100% and not 300% but still feel this is not expected, since a few minutes before the CPU was at a few percentage point and nothing should have changed.

For debug I sent SIGUSR1 and SIGUSR2, also enabled for ten seconds full logging with "xpra control :1 debug enable all".

I will attach here the new log and the new xpra info

totaam · 2020-04-12T09:48:02Z

2020-04-12 09:48:02: marcelo uploaded file `1.ver2.txt` (178.1 KiB)

totaam · 2020-04-12T09:48:16Z

2020-04-12 09:48:16: marcelo uploaded file `xpra.info.ver2.txt` (330.7 KiB)

totaam · 2020-04-12T10:05:48Z

2020-04-12 10:05:48: marcelo commented

Trying to add some other info through GDB:

(gdb) bt
#0  0x00007f67815edbf9 in __GI___poll (fds=0x32a8620, nfds=4, timeout=500) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f6778cb15c9 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f6778cb1962 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f677148da25 in gtk_main () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#4  0x00007f677fe6bdae in ffi_call_unix64 () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#5  0x00007f677fe6b71f in ffi_call () at /usr/lib/x86_64-linux-gnu/libffi.so.6
#6  0x00007f677410ce6a in  () at /usr/lib/python3/dist-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so
#7  0x00007f677410ea48 in  () at /usr/lib/python3/dist-packages/gi/_gi.cpython-36m-x86_64-linux-gnu.so
#8  0x00000000005aa6ec in _PyObject_FastCallKeywords ()
#9  0x000000000050abb3 in  ()
#10 0x000000000050c5b9 in _PyEval_EvalFrameDefault ()
#11 0x0000000000509d48 in  ()
#12 0x000000000050aa7d in  ()
#13 0x000000000050c5b9 in _PyEval_EvalFrameDefault ()
#14 0x0000000000508245 in  ()
#15 0x000000000050a080 in  ()
#16 0x000000000050aa7d in  ()
#17 0x000000000050c5b9 in _PyEval_EvalFrameDefault ()
#18 0x0000000000508245 in  ()
#19 0x000000000050a080 in  ()
#20 0x000000000050aa7d in  ()
#21 0x000000000050c5b9 in _PyEval_EvalFrameDefault ()
#22 0x0000000000508245 in  ()
#23 0x000000000050a080 in  ()
#24 0x000000000050aa7d in  ()
#25 0x000000000050c5b9 in _PyEval_EvalFrameDefault ()
#26 0x0000000000508245 in  ()
#27 0x000000000050a080 in  ()
#28 0x000000000050aa7d in  ()
#29 0x000000000050c5b9 in _PyEval_EvalFrameDefault ()
#30 0x0000000000508245 in  ()
#31 0x000000000050a080 in  ()
#32 0x000000000050aa7d in  ()
#33 0x000000000050c5b9 in _PyEval_EvalFrameDefault ()
#34 0x0000000000508245 in  ()
#35 0x000000000050b403 in PyEval_EvalCode ()
#36 0x0000000000635222 in  ()
#37 0x00000000006352d7 in PyRun_FileExFlags ()
#38 0x0000000000638a8f in PyRun_SimpleFileExFlags ()
#39 0x0000000000639631 in Py_Main ()
#40 0x00000000004b0f40 in main ()
(gdb) info threads
  Id   Target Id         Frame
* 1    Thread 0x7f6781acf740 (LWP 27028) "xpra" 0x00007f67815edbf9 in __GI___poll (fds=0x32a8620, nfds=4, timeout=500) at ../sysdeps/unix/sysv/linux/poll.c:29
  2    Thread 0x7f6769e4e700 (LWP 27048) "gmain" 0x00007f67815edbf9 in __GI___poll (fds=0x2fe9940, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  3    Thread 0x7f676a64f700 (LWP 27049) "gdbus" 0x00007f67815edbf9 in __GI___poll (fds=0x2ff7820, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  4    Thread 0x7f676ae50700 (LWP 27080) "xpra" 0x00007f67812ca6d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f67000018b0)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  5    Thread 0x7f673bfff700 (LWP 27199) "xpra" 0x00007f67812ca6d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f6734007280)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  6    Thread 0x7f6738fcd700 (LWP 18437) "xpra" 0x00007f67815fba66 in __libc_recv (fd=12, buf=0x7f67642d4480, len=65536, flags=0)
    at ../sysdeps/unix/sysv/linux/recv.c:28
  7    Thread 0x7f673b7fe700 (LWP 18445) "xpra" 0x00007f6751ded398 in ?? ()
   from /usr/lib/python3/dist-packages/xpra/server/window/motion.cpython-36m-x86_64-linux-gnu.so
  8    Thread 0x7f6721a23700 (LWP 18578) "xpra" 0x00007f67815fba66 in __libc_recv (fd=12, buf=0x7f671c0370e0, len=65536, flags=0)
    at ../sysdeps/unix/sysv/linux/recv.c:28
  9    Thread 0x7f6752c33700 (LWP 18579) "xpra" 0x00007f67812ca6d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f674401b440)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  10   Thread 0x7f6751430700 (LWP 18581) "xpra" 0x00007f67812ca6d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f6748000e70)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  11   Thread 0x7f6724e80700 (LWP 18582) "xpra" 0x00007f67812ca6d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f674c02d020)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  12   Thread 0x7f6751c31700 (LWP 18584) "xpra" 0x00007f67812ca6d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f673c016a80)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  13   Thread 0x7f67397ce700 (LWP 18592) "xpra" 0x00007f67815e90b4 in __GI___libc_read (fd=14, buf=0x7f674002dec0, nbytes=65536)
    at ../sysdeps/unix/sysv/linux/read.c:27
  14   Thread 0x7f6722dfc700 (LWP 18628) "xpra" 0x00007f67812ca6d6 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f6714002260)

totaam · 2020-04-12T11:23:43Z

2020-04-12 11:23:43: antoine commented

Suddenly i noticed firefox was not responding correctly, the mouse pointer would stay as the hand symbol no matter how much i move the mouse (as if i was hovering over a link) and the program was not responding correctly to mouse clicks, still responding correctly to keyboard presses.
A focus bug has just been fixed recently: #2723.
This could help here, try 3.0.9-RC or 4.0-RC builds from [https://xpra.org/beta].

I tried to reinit and refresh the windows but it did not help much; disconnecting the xpra client and reconnected fixed it.
This sounds like a client bug, have you tried running without opengl acceleration in the client?
(especially if this is an Intel iGPU)

Still I also noticed the CPU fan working non stop and thought this might be a reproduction of the bug.
You still have not enabled python-lz4...
Did the CPU stay on 100% for long?
It is possible for the CPU load to go high until the server realizes that the client has disconected.
In some (bad) cases, this can take up to 1 minute.

I do see something unexpected in your output:
2020-04-12 11:31:28,035 SIGUSR1
2020-04-12 11:31:28,035 found 12 frames:
(..)
2020-04-12 11:31:32,393 SIGUSR2
2020-04-12 11:31:32,443 found 101 frames:
12 frames is normal-ish: I get just 9 with my server and one client connected, but close enough.

101 frames in the garbage collector's queue, that's huge. I get just 2 frames there, no matter how many times I re-connect the client.
You seem to have dozens of client connection threads sitting there (encode loop and the read / write / parse / format network threads) - are there any SSH processes lingering on your server too?

Is it possible for you to try plain TCP or SSL?

totaam · 2020-04-12T13:05:52Z

2020-04-12 13:05:52: marcelo commented

Did the CPU stay on 100% for long?
It is possible for the CPU load to go high until the server realizes that the client has disconected.
In some (bad) cases, this can take up to 1 minute.
This is still happening right now (4 hours later).

You seem to have dozens of client connection threads sitting there (encode loop and the read / write / parse / format network threads) - are there any SSH processes lingering on your server too?
I have ssh processes up, but they might be the expected number of processes, I don't know. I will share with you the full pstree of the linux server, so you can tell me yourself.

Is it possible for you to try plain TCP or SSL?
Yes, of course. But i have the reproduction live in my machine, ready in case we need to extract more info, if you want me to dump the current reproduction and start all over again I will try.

totaam · 2020-04-12T13:06:24Z

2020-04-12 13:06:24: marcelo uploaded file `pstree.ver.txt` (49.8 KiB)

totaam · 2020-04-12T15:18:53Z

There doesn't seem to be any suspicious processes in there.
Not sure what else to suggest.

totaam · 2020-04-12T22:20:42Z

2020-04-12 22:20:42: marcelo commented

Ok, miraculously I was able to reproduce it in a short period of time.
This is the complete procedure (less than one minute):

start server on ubuntu

connect from windows client

open firefox

maximize firefox window (sidenote: my window client fails to draw this correctly when maximized, is it a clue?)

disconnect the windows client

reconnect from windows client

At this point top shows xpra with 100% cpu. It reproduces consistently and the list of steps is minimal, i.e. removing anything from this steps makes the bug not to appear.

Note: This time i reproduced with TCP connection, without compression and without codecs.

totaam · 2020-04-13T08:08:02Z

I can reproduce some problems with these exact steps!

First, the window geometry ends up completely wrong, which causes problems during encoding:

error processing encode queue at index 0
item=(32751, 95, 1238.575040716, 1238.753025352, XShmImageWrapper(BGRX: 0, 0, 32751, 95), 'webp', 245, {'window-size': (32751, 95)}, 0)
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/xpra/server/window/window_video_source.py", line 997, in encode_from_queue
    self.make_data_packet_cb(*item)
  File "/usr/lib/python3/dist-packages/xpra/server/window/window_source.py", line 1804, in make_data_packet_cb
    packet = self.make_data_packet(damage_time, process_damage_time, image, coding, sequence, options, flush)
  File "/usr/lib/python3/dist-packages/xpra/server/window/window_source.py", line 2322, in make_data_packet
    ret = encoder(coding, image, options)
  File "/usr/lib/python3/dist-packages/xpra/server/window/window_source.py", line 2428, in webp_encode
    return webp_encode(image, self.supports_transparency, q, s, self.content_type)
  File "/usr/lib/python3/dist-packages/xpra/server/picture_encode.py", line 33, in webp_encode
    cdata, client_options = enc_webp.encode(image, quality, speed, supports_transparency, content_type)
  File "xpra/codecs/webp/encoder.pyx", line 403, in xpra.codecs.webp.encoder.encode
Exception: this image is too big for webp: 32751x95

We shouldn't even attempt to compress anything this wide!

I guess we keep retrying, and eventually the compress queue ends up blocked:

send_delayed for wid 2, delaying again because too many pixels are waiting to be encoded: 116280

totaam · 2020-04-13T11:31:13Z

Lots of fixes:

r26105 if the window has invalid dimensions, don't even attempt to handle damage events
r26106 record all damage events, even when discarding them
r26107 lower max window size to catch more invalid values (ie: the ones we get here)
r26108 webp has a size limit of 16383x16383

With these fixes (key ones backported to v3 in 26109 + 26110), I am unable to get the server stuck at all.

There are 3.0.9-RC builds in the beta area with those fixes included.
@marcelo does that fix things for you?

The Firefox window still doesn't display properly in maximized state, and I will try to fix that next, but that's less critical than the bugs fixed above.
It seems that it is GTK3 on MS Windows that is sending us bogus window dimensions:

window_state_updated(..) state updates: {'maximized': True, 'focused': True}, actual updates: {'maximized': True, 'focused': True}, server updates: {'maximized': True, 'focused': True}
['configure-window', 2, 0, 23, 32751, 95, {}, 0, {'maximized': True, 'focused': True}, False, 2, (898, 242), ['mod2']]

totaam · 2020-04-13T15:13:30Z

The Firefox window still doesn't display properly in maximized state..

Interesting, GTK gives us an invalid window geometry and so does the OS.

The bug goes away, if I use XPRA_WIN32_WINDOW_HOOKS=0 or XPRA_SET_SIZE_CONSTRAINTS=0 with the client.
It also does not occur with v4 servers, only v3.

With v3:

process_new_common: [3, 0, 0, 703, 100, {b'xid': b'0x800003', b'client-machine': b'desktop-eth0', b'pid': 81851, \
    b'title': b'Mozilla Firefox', b'role': b'browser', b'class-instance': (b'Navigator', b'Firefox'), \
    b'group-leader-xid': 8388609, b'window-type': (b'NORMAL',), \
    b'size-constraints': {b'base-size': (450, 95), b'gravity': 1, b'minimum-size': (450, 95), b'maximum-size': (32766, 32766)}, \
    b'icon-title': b'Mozilla Firefox', b'iconic': False}], ..., OR=False
apply_geometry_hints({b'max_width': 32766, b'max_height': 32766, b'min_width': 450, b'min_height': 95, b'base_width': 450, b'base_height': 95}) \
    geometry=<Gdk.Geometry object at 0x0000000028d8e7c0 (void at 0x000000002226cae0)>, hints=<flags GDK_HINT_MIN_SIZE | GDK_HINT_MAX_SIZE | GDK_HINT_BASE_SIZE of type Gdk.WindowHints>

followed by a maximize event with size 32751x95.

With v4:

process_new_common: [3, 0, 0, 703, 100, {b'xid': b'0x800003', b'client-machine': b'desktop-eth0', b'pid': 83293, \
    b'title': b'Mozilla Firefox', b'role': b'browser', b'class-instance': (b'Navigator', b'Firefox'), \
    b'group-leader-xid': 8388609, b'window-type': (b'NORMAL',), \
    b'size-constraints': {b'base-size': (450, 95), b'gravity': 1, b'minimum-size': (450, 95)}, \
    b'icon-title': b'Mozilla Firefox', b'iconic': False}],  ... OR=False
apply_geometry_hints({b'min_width': 450, b'min_height': 95, b'base_width': 450, b'base_height': 95}) \
    geometry=<Gdk.Geometry object at 0x0000000025bdd5e0 (void at 0x00000000223e5670)>, hints=<flags GDK_HINT_MIN_SIZE | GDK_HINT_BASE_SIZE of type Gdk.WindowHints>

Looks like setting a max-size is what's causing the problem, somewhat reminiscent of #2214.

totaam · 2020-04-13T15:52:45Z

That's because Firefox uses some strange size hints:

updated: size-hints={'base-size': (450, 95), 'gravity': 1, 'minimum-size': (450, 95), 'maximum-size': (32766, 32766)}

And we try to honour it but the maximum size triggers some weird behaviour on win32.

The quick and dirty workaround is in r26112 (will backport to v3), I will try to find a more correct solution.

totaam · 2020-04-13T16:02:25Z

2020-04-13 16:02:25: marcelo commented

Ok. The CPU issue does not reproduce after I upgraded to beta. Thanks Antoine, that was amazingly fast.
Do you think there is something i can do to mitigate the maximization issue?
And also: Should i upgrade the client to beta too?

totaam · 2020-04-13T16:43:32Z

Do you think there is something i can do to mitigate the maximization issue?
And also: Should i upgrade the client to beta too?

Yes, the beta client should fix that too, let me know if you still have problems.
Otherwise, can we close this ticket?

I have just uploaded some new win32 builds: https://xpra.org/beta/windows/

totaam · 2020-04-14T04:36:01Z

So the problem with maximized state on ms windows is twofold:

if we have set a maximum size for a window then the OS will resize the window to that size, not the screen size. Since some X11 applications like Firefox set huge maximum sizes... this leads to the problems we saw, which is why filtering the large maximum sizes solves the problem.
something (GTK3?) seems to confuse the OS, and the window is resized to the maximum width and minimum height (no idea why)

Another way to fix this is to re-enable the XPRA_WIN32_MAX_SIZE_HINT hook and disable GTK's size-hints handling altogether.
Patch attached.
I'm not applying that because it is more intrusive, for no real beneffit.

totaam · 2020-04-14T04:37:02Z

2020-04-14 04:37:02: antoine uploaded file `max.patch` (3.3 KiB)

alternative fix

totaam closed this as completed Apr 13, 2020

totaam added the v3.0.x label Jan 22, 2021

totaam mentioned this issue Jan 22, 2021

Mouse pointer does not return to normal after drag and drop #2733

Open

totaam mentioned this issue Apr 28, 2022

maximization goes wrong with MS Windows clients #3533

Closed

totaam mentioned this issue May 3, 2022

Server occasionally sends incorrectly-sized (16384x16384, 450x16384, 563x16384) windows to client (4.3-r30545) #3517

Closed

totaam mentioned this issue Jul 12, 2022

dealing with very large client screen sizes #969

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

300% cpu utilization when detached with no windows opened #2714

300% cpu utilization when detached with no windows opened #2714

totaam commented Apr 7, 2020

totaam commented Apr 7, 2020 •

edited

Loading

totaam commented Apr 7, 2020

totaam commented Apr 7, 2020

totaam commented Apr 7, 2020

totaam commented Apr 7, 2020

totaam commented Apr 7, 2020

totaam commented Apr 7, 2020 •

edited

Loading

totaam commented Apr 8, 2020 •

edited

Loading

totaam commented Apr 8, 2020

totaam commented Apr 12, 2020

totaam commented Apr 12, 2020

totaam commented Apr 12, 2020

totaam commented Apr 12, 2020

totaam commented Apr 12, 2020

totaam commented Apr 12, 2020

totaam commented Apr 12, 2020

totaam commented Apr 12, 2020 •

edited

Loading

totaam commented Apr 12, 2020

totaam commented Apr 13, 2020 •

edited

Loading

totaam commented Apr 13, 2020 •

edited

Loading

totaam commented Apr 13, 2020 •

edited

Loading

totaam commented Apr 13, 2020 •

edited

Loading

totaam commented Apr 13, 2020

totaam commented Apr 13, 2020 •

edited

Loading

totaam commented Apr 14, 2020 •

edited

Loading

totaam commented Apr 14, 2020

300% cpu utilization when detached with no windows opened #2714

300% cpu utilization when detached with no windows opened #2714

Comments

totaam commented Apr 7, 2020

2020-04-07 10:12:46: marcelo created the issue

totaam commented Apr 7, 2020 • edited Loading

totaam commented Apr 7, 2020

2020-04-07 10:16:25: marcelo commented

totaam commented Apr 7, 2020

2020-04-07 10:17:32: marcelo uploaded file 1.log (48.1 KiB)

totaam commented Apr 7, 2020

2020-04-07 10:19:01: marcelo uploaded file xpra.info (180.8 KiB)

totaam commented Apr 7, 2020

2020-04-07 10:21:18: marcelo uploaded file xpra.showconfig (10.3 KiB)

totaam commented Apr 7, 2020

2020-04-07 10:23:04: marcelo commented

totaam commented Apr 7, 2020 • edited Loading

totaam commented Apr 8, 2020 • edited Loading

totaam commented Apr 8, 2020

2020-04-08 08:16:11: antoine commented

totaam commented Apr 12, 2020

2020-04-12 09:47:13: marcelo commented

totaam commented Apr 12, 2020

2020-04-12 09:48:02: marcelo uploaded file 1.ver2.txt (178.1 KiB)

totaam commented Apr 12, 2020

2020-04-12 09:48:16: marcelo uploaded file xpra.info.ver2.txt (330.7 KiB)

totaam commented Apr 12, 2020

2020-04-12 10:05:48: marcelo commented

totaam commented Apr 12, 2020

2020-04-12 11:23:43: antoine commented

totaam commented Apr 12, 2020

2020-04-12 13:05:52: marcelo commented

totaam commented Apr 12, 2020

2020-04-12 13:06:24: marcelo uploaded file pstree.ver.txt (49.8 KiB)

totaam commented Apr 12, 2020 • edited Loading

totaam commented Apr 12, 2020

2020-04-12 22:20:42: marcelo commented

totaam commented Apr 13, 2020 • edited Loading

totaam commented Apr 13, 2020 • edited Loading

totaam commented Apr 13, 2020 • edited Loading

totaam commented Apr 13, 2020 • edited Loading

totaam commented Apr 13, 2020

2020-04-13 16:02:25: marcelo commented

totaam commented Apr 13, 2020 • edited Loading

totaam commented Apr 14, 2020 • edited Loading

totaam commented Apr 14, 2020

2020-04-14 04:37:02: antoine uploaded file max.patch (3.3 KiB)

totaam commented Apr 7, 2020 •

edited

Loading

2020-04-07 10:17:32: marcelo uploaded file `1.log` (48.1 KiB)

2020-04-07 10:19:01: marcelo uploaded file `xpra.info` (180.8 KiB)

2020-04-07 10:21:18: marcelo uploaded file `xpra.showconfig` (10.3 KiB)

totaam commented Apr 7, 2020 •

edited

Loading

totaam commented Apr 8, 2020 •

edited

Loading

2020-04-12 09:48:02: marcelo uploaded file `1.ver2.txt` (178.1 KiB)

2020-04-12 09:48:16: marcelo uploaded file `xpra.info.ver2.txt` (330.7 KiB)

2020-04-12 13:06:24: marcelo uploaded file `pstree.ver.txt` (49.8 KiB)

totaam commented Apr 12, 2020 •

edited

Loading

totaam commented Apr 13, 2020 •

edited

Loading

totaam commented Apr 13, 2020 •

edited

Loading

totaam commented Apr 13, 2020 •

edited

Loading

totaam commented Apr 13, 2020 •

edited

Loading

totaam commented Apr 13, 2020 •

edited

Loading

totaam commented Apr 14, 2020 •

edited

Loading

2020-04-14 04:37:02: antoine uploaded file `max.patch` (3.3 KiB)