I just had to kill my xfwm4, because my xfce4 was unresponsive even though memory and cpu time were still available. Also xfwm4-4.14 seems to use a lot of cpu time, I had this system up for a bit over a day and xfwm used more cpu time than any other program, with over 6h that's almost a fourth of the systems uptime, this seems odd.. 01:49:04 up 1 day, 48 min, 2 users, load average: 0,05, 0,38, 0,81 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 3690 4.2 1.5 2030548 127972 tty7 Ssl+ Sep15 62:20 /usr/bin/X :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch neuron 3826 26.0 1.5 1578884 123848 ? Sl Sep15 385:41 xfwm4 --display :0.0 --sm-client-id 22a5ae37f-deb5-491a-8633-7252e4517781
I can confirm that I am experiencing the same: 942 kamen 20 0 776172 99720 53256 S 27.2 0.1 234:58.44 xfwm4 inxi -Fxz output in case it helps: System: Host: iberia Kernel: 5.3.0-arch1-1-ARCH x86_64 bits: 64 compiler: gcc v: 9.1.0 Desktop: Xfce 4.14.1 Distro: Arch Linux Machine: Type: Desktop Mobo: ASUSTeK model: ROG CROSSHAIR VIII HERO (WI-FI) v: Rev X.0x serial: <filter> UEFI: American Megatrends v: 1001 date: 09/09/2019 Battery: Device-1: hidpp_battery_0 model: Logitech Wireless Mouse MX Master 2S charge: 50% (should be ignored) status: N/A CPU: Topology: 12-Core model: AMD Ryzen 9 3900X bits: 64 type: MT MCP arch: Zen L2 cache: 6144 KiB flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 182142 Speed: 3117 MHz min/max: 2200/3800 MHz Core speeds (MHz): 1: 3117 2: 2936 3: 2004 4: 2477 5: 2636 6: 2123 7: 3558 8: 1894 9: 2827 10: 2043 11: 2797 12: 2199 13: 3887 14: 3578 15: 1876 16: 1917 17: 2760 18: 2065 19: 2825 20: 1875 21: 3292 22: 2443 23: 2642 24: 1941 Graphics: Device-1: NVIDIA GP106 [GeForce GTX 1060 6GB] vendor: eVga.com. driver: nvidia v: 435.21 bus ID: 0a:00.0 Display: x11 server: X.org 1.20.5 driver: nvidia resolution: <xdpyinfo missing> OpenGL: renderer: GeForce GTX 1060 6GB/PCIe/SSE2 v: 4.6.0 NVIDIA 435.21 direct render: Yes Audio: Device-1: NVIDIA GP106 High Definition Audio vendor: eVga.com. driver: snd_hda_intel v: kernel bus ID: 0a:00.1 Device-2: Advanced Micro Devices [AMD] Starship/Matisse HD Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel bus ID: 0c:00.4 Device-3: Corsair type: USB driver: hid-generic,snd-usb-audio,usbhid bus ID: 3-2.3:4 Device-4: Logitech HD Webcam C525 type: USB driver: snd-usb-audio,uvcvideo bus ID: 3-2.1:3 Sound Server: ALSA v: k5.3.0-arch1-1-ARCH Network: Device-1: Realtek vendor: ASUSTeK driver: N/A port: e000 bus ID: 04:00.0 Device-2: Intel I211 Gigabit Network vendor: ASUSTeK driver: igb v: 5.6.0-k port: d000 bus ID: 05:00.0 IF: enp5s0 state: up speed: 1000 Mbps duplex: full mac: <filter> Device-3: Intel Wi-Fi 6 AX200 driver: iwlwifi v: kernel port: d000 bus ID: 06:00.0 IF: wlp6s0 state: down mac: <filter> Drives: Local Storage: total: 4.26 TiB used: 1.30 TiB (30.5%) ID-1: /dev/nvme0n1 vendor: Corsair model: Force MP600 size: 1.82 TiB ID-2: /dev/sda vendor: Samsung model: SSD 850 EVO 500GB size: 465.76 GiB ID-3: /dev/sdb vendor: Western Digital model: WD2001FFSX-68JNUN0 size: 1.82 TiB ID-4: /dev/sdc vendor: Intel model: SSDSC2CW180A3 size: 167.68 GiB ID-5: /dev/sdd type: USB vendor: Generic model: Flash Disk size: 1.88 GiB Partition: ID-1: / size: 1.67 TiB used: 216.62 GiB (12.6%) fs: ext4 dev: /dev/nvme0n1p3 ID-2: swap-1 size: 119.21 GiB used: 11.8 MiB (0.0%) fs: swap dev: /dev/nvme0n1p2 Sensors: System Temperatures: cpu: 44.5 C mobo: 32.0 C gpu: nvidia temp: 59 C Fan Speeds (RPM): cpu: 0 fan-1: 938 fan-2: 976 fan-3: 0 fan-4: 626 fan-5: 0 fan-6: 0 fan-7: 0 gpu: nvidia fan: 29% Info: Processes: 468 Uptime: 23h 56m Memory: 125.73 GiB used: 14.56 GiB (11.6%) Init: systemd Compilers: gcc: 9.1.0 Shell: zsh v: 5.7.1 inxi: 3.0.36
I have resolved this issue on my machine with the help of diogenes_ & BeNZ on #xfce. First we ran the following commands to ensure that I was using the nvidia module was loaded and to see if the llvmpipe (CPU/Software Rendering) was being used: $ lsmod | grep nvidia nvidia_drm 57344 7 nvidia_modeset 1126400 14 nvidia_drm nvidia 19558400 660 nvidia_modeset drm_kms_helper 212992 1 nvidia_drm drm 516096 10 drm_kms_helper,nvidia_drm ipmi_msghandler 65536 2 ipmi_devintf,nvidia $ glxinfo | grep -i "direct rendering\|renderer string" direct rendering: Yes OpenGL renderer string: GeForce GTX 1060 6GB/PCIe/SSE2 Based on that they recommended that I try to run: $ xfwm4 --vblank=off --replace This immediately dropped my CPU usage from 35% down to 0.7%. For more reference on this option see: https://github.com/xfce-mirror/xfwm4/blob/master/COMPOSITOR Before making the change persistent, I navigated into nvidia-settings and checked the value of "Force Composition Pipeline" & "Force Full Composition Pipeline" under X Server Display Configuration. Both of these settings were disabled. I then enabled "Force Full Composition Pipeline" and rebooted. My usage now sitting around 1% without having to make any other changes to Xfce. Also, I did try to disable window composition with "xfconf-query --channel xfwm4 -p /general/use_compositing -s false" and in the xfwm4-tweak-settings UI - but the usage remained high. Hope it helps
For me this behaviour happens sporadically, I'm using an AMD GPU, probably this just behaves a bit different there.
Can you please try the current code in master?
While the Nvidia settings did initially make a difference, it wasn't a lasting change. I ended up doing "xfconf-query -c xfwm4 -p /general/vblank_mode -t string -s off", which combined with the Nvidia settings have made a big difference. xfwm4 process is sitting at about 7% after a couple of days. Still not perfect yet but it is workable. I will need to try the other vblank_mode options at some point to compare the results.
Is with *current* master (ie with https://git.xfce.org/xfce/xfwm4/commit/?id=e5462de)?
The high CPU usage of xfwm4 brought me here. I use: me[~]> xfwm4 -V This is xfwm4 version 4.14.0 (revision ed87ef663) for Xfce 4.14 Released under the terms of the GNU General Public License. Compiled against GTK+-3.22.30, using GTK+-3.22.30. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: Yes - Embedded compositor: Yes - Epoxy support: Yes - KDE systray proxy (deprecated): No I'm running it on a Lenovo Thinkpad X1C6. Graphics driver is: Intel Corporation UHD Graphics 620. Kernel is 5.0.0-29-generic.
(In reply to Oscar Franzén from comment #7) > The high CPU usage of xfwm4 brought me here. I use: > > me[~]> xfwm4 -V > This is xfwm4 version 4.14.0 (revision ed87ef663) for Xfce 4.14 > Released under the terms of the GNU General Public License. > Compiled against GTK+-3.22.30, using GTK+-3.22.30. > > Build configuration and supported features: > - Startup notification support: Yes > - XSync support: Yes > - Render support: Yes > - Xrandr support: Yes > - Xpresent support: Yes > - Embedded compositor: Yes > - Epoxy support: Yes > - KDE systray proxy (deprecated): No > > I'm running it on a Lenovo Thinkpad X1C6. Graphics driver is: Intel > Corporation UHD Graphics 620. Kernel is 5.0.0-29-generic. I have applied: xfconf-query -c xfwm4 -p /general/vblank_mode -t string -s off and I will see if it helps.
(In reply to Oscar Franzén from comment #7) > The high CPU usage of xfwm4 brought me here. I use: I would rather not use this bug for any CPU usage issue. A higher CPU usage with GL for vblank is to be expected. For intel, just use xpresent, as this works well... $ xfconf-query -c xfwm4 -p /general/vblank_mode -s xpresent
(In reply to Olivier Fourdan from comment #9) > $ xfconf-query -c xfwm4 -p /general/vblank_mode -s xpresent I have applied this one and restarted. It seems to help.
I'm experiencing the same issue. xfwm4 CPU usage is normally <= 2% when dragging windows, alt-tabbing etc. But, then it starts to climb up when changing focus or moving windows to 15-20%. Window movements are noticable "choppy", and changing focus is slow. It continues to degrade until I pkill xfwm, and it restarts and works fine for a day or so and the problem repeats. I am on a ThinkPad T410, Core i5 M, with Intel graphics. I have tried all 3 vblank modes mentioned (off, xpresent, glx). None seem to help. I've tried changing my theme mentioned in other posts. Doesn't help. This happened when I upgraded from 4.12.5-1 -> 4.14.0-1. > This is xfwm4 version 4.14.0 (revision ed87ef663) for Xfce 4.14 > Released under the terms of the GNU General Public License. > Compiled against GTK+-3.24.10, using GTK+-3.24.12. > Build configuration and supported features: > - Startup notification support: Yes > - XSync support: Yes > - Render support: Yes > - Xrandr support: Yes > - Xpresent support: Yes > - Embedded compositor: Yes > - Epoxy support: Yes > - KDE systray proxy (deprecated): No
I noticed recently that I don't think the issue is solved for me. xfwm4 CPU usage goes up without any reason. I noticed it when running on battery. Not really sure how to deal with this. Thinking about downgrading to the old xfce4 but would like to avoid it.
Experiencing same issue since upgrading to 4.14.0. After a while Xfwm4 slows down especially with windows that have video, e.g. video calls or Youtube. My temporary solution now is to bind xfwm4 --replace to a shortcut, this fixes all the problems. I am running on Intel integrated graphics.
I find the latest versions of Xfwm4 to be acting very weird. After some time, it starts getting very slow, eg. raising my quake-style terminal takes seconds, and htop shows it is xfwm4 sucking a lot of CPU meanwhile. Restarting Xfwm4 fixes the problem temporarily. Also, I have noticed that, when I'm looking at some websites with Chrome (sorry I failed to take notes of which), Xfwm4 starts using a lot of CPU. If I switch tabs it stops. Coming back to the same website shows this happening again. Things I tried: * xfconf-query -c xfwm4 -p /general/vblank_mode -s xpresent && xfwm4 --replace -- xpresent seems to make no difference, and a line appears on the screen during scrolling. * Set vblank_mode to auto, and compiled from Git -- the problem just took longer to appear, I had to restart Xfwm4 after 7 days instead of only 2. But this could also just mean I had a different usage pattern during these days. I was using Xfwm4 4.14.0 from Xubuntu 19.10, and have been using 4.14.0git.e1f2e340 (revision e1f2e340) for the last week. ~> inxi -SMGz System: Host: laptop Kernel: 5.3.0-18-generic x86_64 bits: 64 Desktop: Xfce 4.14.1 Distro: Ubuntu 19.10 (Eoan Ermine) Machine: Type: Laptop System: LENOVO product: 80JE v: Lenovo G40-80 serial: <filter> Mobo: LENOVO model: Lancer 4A1 v: SDK0E50515 STD serial: <filter> UEFI: LENOVO v: B0CNA0WW date: 09/30/2016 Graphics: Device-1: Intel HD Graphics 5500 driver: i915 v: kernel Display: x11 server: X.Org 1.20.5 driver: modesetting unloaded: fbdev,vesa resolution: 1366x768~60Hz OpenGL: renderer: Mesa DRI Intel HD Graphics 5500 (Broadwell GT2) v: 4.5 Mesa 19.2.1
One example of a webpage I mentioned above, where Xfwm4 starts using CPU when opening it with Chrome, is https://www.phonearena.com/news/Trump-to-allow-some-U.S.-firms-to-ship-to-Huawei_id119607 I have downgraded to 4.12.5-1ubuntu1, and none of these problems happen.
(In reply to Teresa e Junior from comment #15) > One example of a webpage I mentioned above, where Xfwm4 starts using CPU > when opening it with Chrome, is > https://www.phonearena.com/news/Trump-to-allow-some-U.S.-firms-to-ship-to-Huawei_id119607 Well, that page makes *chrome* itself eat 100% CPU here, not xfwm4.
(In reply to Olivier Fourdan from comment #16) > (In reply to Teresa e Junior from comment #15) > > One example of a webpage I mentioned above, where Xfwm4 starts using CPU > > when opening it with Chrome, is > > https://www.phonearena.com/news/Trump-to-allow-some-U.S.-firms-to-ship-to-Huawei_id119607 > > Well, that page makes *chrome* itself eat 100% CPU here, not xfwm4. I also found that very weird, but it was xfwm4 eating a lot of CPU too, besides Chrome, on 4.14.0git.e1f2e340. I downgraded Xfwm4 and now only Chrome does. Probably related to hardware acceleration enabled on Chrome with the compositor enabled.
I've noticed that xfwm4 has begun hanging when either the whisker menu or the Visual Studio Code "are you sure you want to discard Git changes" dialog box appear. The hangs last ~10-30 seconds. Disabling compositing fixes them.
Same issue here. Everything runs fine with my machine (Xeon W3680 and GTX 1060 on Arch with XFCE/XFWM 4.14.0-1) unless I leave it on overnight. When I come back to it the next day, it's basically unusable due to major lag, stutter, and freezing. It happens no matter what I'm doing, anything from switching windows, displaying window animations, and when trying to play video games (anything from the original Doom to Subnautica and everything in between) or watch a video (with VLC, parole, Hulu, Netflix, Chromium or Firefox, doesn't matter). I don't mean slight hiccups; they're 0.5 - 5+ second delays. Video playback is a constant desync and stutterfest, sometimes like watching some kind of slideshow and the guy with the controls had way too much coffee or something. I just noticed CPU use is indeed rising to when moving or resizing windows from ~0-1% to ~10%+ usage. So without hyperthreading, that would mean it's using 20% of a hexacore processor, or I guess 100% if it were one core, which seems bit excessive and perhaps is part of the issue. xfwm --replace works just like as a reboot would and stops all the stutter and high CPU use. Well it fixes it for now, anyway; I'm guessing the issue will recur with sufficient uptime.
Is this bug related to this https://github.com/Guake/guake/issues/1666 ? I do not observe problems on other apps than guake but might still be related.
After some time, I'm observing the behavior in Terminator app too. I tried running "xfwm --replace" but it timed out trying to replace xfwm, so I ran the command again, and after a while trying it did replace xfwm. When it was done, the Guake problem disappeared (until when?). After this too, there was a very noticeable speed improvement when switching to another desktop. It used to take one full second and I got used to it, so didn't think it was a problem, but after replacing the wm instance, switching desktops takes much less than a second. Don't know if it's related.
Hi, just to say I can reproduce this bug too, and I can make the same observations (high CPU usage by xfwm4, long delay to switch windows, video playback a bit laggy, etc.). It started around november 2019, and it occurs after a long run (several days in my case). Replacing xfwm4 temporarily fixes the behavior, thanks for the advice. I'm running Archlinux x64, so with latest available version of Xfce. Not using Guake though, only xfce4-terminal with the native drop-down feature. But the behavior is the same and it takes 2-3 seconds to make it appear at some point. Also using the "Arc-Darker" theme ("Arc-Dark" for the windows) with the compositor enabled. ``` $ xfwm4 --version This is xfwm4 version 4.14.0 (revision ed87ef663) for Xfce 4.14 Released under the terms of the GNU General Public License. Compiled against GTK+-3.24.10, using GTK+-3.24.13. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: Yes - Embedded compositor: Yes - Epoxy support: Yes - KDE systray proxy (deprecated): No ```
Hi, I'm also experiencing this bug. I'm using "Arc" as my window and display theme. This happens on several of my computers, all running Linux 5.5.8, one with amdgpu and one with i915. It seems to happen after a while of uptime, sometimes after a couple of hours, sometimes after S3 sleep. Killing xfwm4 and then restarting it temporarily fixes the issue. Additional version info: This is xfwm4 version 4.14.0git.5ea89c (revision 5ea89c) for Xfce 4.14 Released under the terms of the GNU General Public License. Compiled against GTK+-3.24.12, using GTK+-3.24.14. Running Manjaro Linux stable, all packages up-to-date.
Looks like /something/ is leaking yet I am unable to reproduce this on any hardware here so I just cannot tell what. Comment 11 indicates that the vblank mode makes no difference, can you try to reproduce without compositing enabled?
I could try to reproduce this issue on a clean system, if it would help you. Running Manjaro with XFCE, with pavucontrol, Chromium, KeePass (mono), Sublime Text and Thunderbird open (my normal workstation setup) this happens pretty frequently (about every day, sometimes twice a day). lightdm and xscreensaver are also used (just to make sure the environment is identical). After a bit of uptime (my machine had 2 days and 3 hours last time the bug occured) just after waking from S3 this happens, but also sometimes when just using the system.
Did you enable the "TearFree" driver option, or was it enabled automatically? https://wiki.archlinux.org/index.php/intel_graphics#Tearing https://wiki.archlinux.org/index.php/AMDGPU#Tear_free_rendering
(In reply to Theo Linkspfeifer from comment #26) > Did you enable the "TearFree" driver option, or was it enabled automatically? That should not be needed with vblank in the compositor.
I can still reproduce this issue and I'm not sure what exactly causes it. So far I've seen it on ArchLinux and Manjaro Linux, using i915 (on a 3xxx-series Intel CPU), using amdgpu (on a RX 570) and using the propritary nvidia driver (Quadro M2000M). My main laptop (using the i915-driver) shows this behaviour several times a day. I've tried to enable and disable the TearFree driver option (it was enabled by default) and switched themes (from Arc to Adwaita dark and the Default for window decorations). Interestingly, switching to Adwaita seems to have made things much worse? The GUI now started to completely freeze for ~3-5 seconds at random instead of the slowdowns and unresponsiveness of Arc. Killing and restarting xfwm4 will fix this instantly. Is there a way to help debug this issue? I could try to attach gdb to xfwm4, but I'm not sure what to look for.
I'm also experiencing this bug with Ubuntu 20.04 on a Thinkpad T470. It got really bad, having to restart xfwm multiple times a day. Disabling the builtin compositor fixes the problem, as does running `xfwm4 --vblank=off --replace`. Under "Appearance -> Style" and "Appearance -> Icons" I've selected "Yaru". > lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Skylake GT2 [HD Graphics 520] (rev 07) > xfwm4 --version This is xfwm4 version 4.14.1 (revision 44809c49) for Xfce 4.14 Released under the terms of the GNU General Public License. Compiled against GTK+-3.24.17, using GTK+-3.24.18. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: Yes - Embedded compositor: Yes - Epoxy support: Yes - KDE systray proxy (deprecated): No > uname -a Linux hostname 5.4.0-29-generic #33-Ubuntu SMP Wed Apr 29 14:32:27 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
I'm affected by the bug, too. I'm running up to date Arch LInux. I'm using the Arc-Dark theme. > lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Skylake GT2 [HD Graphics 520] (rev 07) > xfwm4 --version This is xfwm4 version 4.14.2 (revision bb38fd909) for Xfce 4.14 Released under the terms of the GNU General Public License. Compiled against GTK+-3.24.20, using GTK+-3.24.20. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: Yes - Embedded compositor: Yes - Epoxy support: Yes - KDE systray proxy (deprecated): No > uname -a Linux 5.6.8-arch1-1 #1 SMP PREEMPT Wed, 29 Apr 2020 16:22:56 +0000 x86_64 GNU/Linux
Well, there've been contradictory indications in this bug report so it's hard for me to identify a pattern, considering that I was never able to reproduce the issue. For example, comment 11 states that changing the vblank mode has no effect (off, glx or xpresent) whereas comment 29 states that turning vblank off solves the problem. So if someone able to reproduce the issue is willing to investigate further, there are a few things that could be tried: 1. check "xrestop" to see if xfwm4 is using a suspicious number of X resources and if that increases over time (note that with compositing, the pixmap memory may be huge, that's normal) 2. check if xfwm4 memory usage grows over time 3. does restarting xfwm4 brings the X resources and/or memory usage back to normal? 4. when the issue occurs, capture a backtrace of the xfwm4 process three few times in raw (e.g. gstack `pidof xfwm4`) to see if xfwm4 is stuck in a busy loop doing something 5. when the issue occurs, try attaching strace to see if it's spending time in some syscall: $ strace -Tttvvs4096 -o xfwm4.trace -p `pidof xfwm4` Then attach the "xfwm4.trace" file to the bug report.
> Well, there've been contradictory indications... I'm 100% sure that running `xfwm4 --vblank=off --replace` prevents the problem from occurring on my laptop at least. I'm not very experienced with this stuff, but I'll try and follow some of those steps this evening / when I get a chance and get back to you.
I typed some of the commands you asked me to while my system was functioning properly. I then left my laptop suspended a while and woke it up. That triggered the symptom of the GUI being unresponsive. I switched to a console with Ctrl Alt F1 and attempted to follow your instructions. Before the problem: > xrestop res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 0a00000 91 4 1 168 940 38321K 25K 38346K 1766 xfwm4 > ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND kzar 1766 1.0 0.2 664404 80116 ? Sl 18:33 0:04 xfwm4 --display :0.0 --sm-client-id 260893b0c-d9f5-4f2f-a932-45ad7efc5c21 During the problem: > xrestop -d 0:0 Unable to open display! > ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND kzar 1766 1.0 0.2 664404 80140 ? Sl 18:33 0:53 xfwm4 --display :0.0 --sm-client-id 260893b0c-d9f5-4f2f-a932-45ad7efc5c21 > pstack 1766 Some message about symbols not being found. > sudo strace -Tttvvs4096 -o xfwm4.trace -p 1766 strace: Process 1766 attached I left strace going for a minute or two, I will attach the xfwm4.trace file. Any idea how I can get the pstack and/or xrestop commands working?
Created attachment 9904 First attempt at producing a xfwm4.trace file for this bug.
(In reply to Dave Vandyke from comment #33) > > > xrestop -d 0:0 > > Unable to open display! Looks like you got the syntax wrong here, it should be "xrestop -d :0.0" > > pstack 1766 > > Some message about symbols not being found. You need to install the debug packages to get the symbols. https://wiki.ubuntu.com/Debug%20Symbol%20Packages > > sudo strace -Tttvvs4096 -o xfwm4.trace -p 1766 > > strace: Process 1766 attached The strace doesn't show much unfortunately, xfwm4 is basically waiting on poll() for events to arrive. xrestop would be interesting, but maybe check the Xorg process for memory and cpu usage as well.
I'm starting to think there might be two distinct problems, which are both fixed by replacing xfwm4. At least there appears to be two separate symptoms on my computer which I have experienced. 1. After the computer has been running for a while, CPU usage of xfwm4 process goes nuts, especially when doing things like opening the whisker menu. That makes the GUI seem jittery or slow. Replacing xfwm4 fixes that straight away. 2. When waking the computer from sleep, there's a random chance that the GUI will become unresponsive. It seems unrelated to how long the laptop's been sleeping. Sometimes after ages the computer will wake successfully, then I'll close and open the lid a few times until the problem shows up. Switching to the console with Ctrl Alt F1, attempting to replace xfwm4 seems to timeout. But with some dance of either switching back to the GUI before it timed out, or retrying the replace a few times the GUI is responsive again. Sometimes there's some weird corruption on the screen or flickering before it becomes responsive again. Sometimes after logging back into the GUI, the window manager is still missing and then I have to open a graphical terminal, replace xfwm4 again to get it finally get it back. So I've had another try at following your instructions, but to clarify it's during symptom #2. > ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND kzar 1363 0.0 0.2 657708 73176 ? Sl 16:47 0:04 xfwm4 --display :0.0 --sm-client-id 260893b0c-d9f5-4f2f-a932-45ad7efc5c21 root 1111 0.1 0.4 1012400 137504 tty7 Ssl+ 16:47 0:19 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch > xrestop -d :0.0 res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 0a00000 91 4 1 166 941 44692K 25K 44718K 1363 xfwm4 > pstack Unfortunately I still get the message about missing symbols, even after following those instructions and succesfully installing the xfwm4-dbgsym package. Any ideas? I'll attach the second attempt at the trace command now.
Created attachment 9905 Second attempt at producing a xfwm4.trace file for this bug.
Now that I see more of a pattern with those symptoms, I'm less certain that `xfwm4 --vblank=off --replace` prevents them from happening on my laptop. I will say though, I have not yet experienced any of the symptoms after typing that command. I'll keep you posted if I ever do.
The issue just occured on my workstation again: This was after suspend again, at 12 days uptime. strace: http://tbspace.de/content/downloads/xfwm4.trace.xz xrestop: https://screenshot.tbspace.de/zqpjgfheicb.png htop: https://screenshot.tbspace.de/toxdbianghj.png backtrace: I've only ever seen this function, nothing else: https://screenshot.tbspace.de/envdgfosujt.png Sorry, gstack doesn't seem to be available on arch? Using gdb on the window manager of the PC you're currently using causes a bit of havoc, I'd need to get a second machine and use SSH. After a "killall xfwm4" and "xfwm4", everything is back to normal. The GUI is snappy again and the resource usage is also back to normal: htop: https://screenshot.tbspace.de/shvajbekicy.png xrestop: https://screenshot.tbspace.de/topxmdgicjs.png Dave: Do you happen to also use KeePass (running in mono)?
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/351. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev