xfwm4 very, very slow - leaking something?

Bug #1864613 reported by Shevek
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Xfwm4
Unknown
Unknown
xfwm4 (Ubuntu)
Medium
Unassigned
Focal
Medium
Sean Davis
Groovy
Medium
Unassigned

Bug Description

[Impact]

 * There is an error leak in the Xfwm4 compositor, causing the system to run slowly after some uptime.

[Test Plan]

 * Enable the Xfwm4 compositor if it is not already. Settings Manager > Window Manager Tweaks > Compositor > Toggle on "Enable Display Compositing".

 * Use the desktop for some time. Reportedly, zooming in and out repeatedly can speed up the process. To zoom, hold Alt, and scroll up and down.

 * The system should start performing poorly after some time, with xfwm4 consuming much of the CPU resources.

 * Once fixed, the system should be much more performant after performing these tasks.

[Where problems could occur]

 * Regression potential should be relatively low, as the release between 4.14.1 and 4.14.5 are bug releases.

 * With window managers, some changes could lead to different behavior and other broken displays. Non-AMD graphics users should also test for regressions.

[Other Info]

 * Please see the Xfwm4 release notes for changes between 4.14.1 and 4.14.5: https://gitlab.xfce.org/xfce/xfwm4/-/blob/xfce-4.14/NEWS#L7-44

[Original Report]

After some uptime, xfwm4 is VERY slow at something, to the point that it's consuming 100% of CPU on a Xeon system and making the system entirely unusable. I don't know who is leaking what, but somebody is clearly leaking something.

I don't have debug symbols, so this is the best I can get:

Thread 1 (Thread 0x7f7b9d98af00 (LWP 27599)):
#0 0x00007f7b9f1e8b7f in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#1 0x00007f7b9f1e8be2 in gdk_x11_display_error_trap_push () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#2 0x0000555c9582c771 in ?? ()
#3 0x00007f7b9ee75248 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007f7b9ee7471e in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f7b9ee74ad0 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007f7b9ee74dc3 in g_main_loop_run () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7 0x00007f7b9f4d2c2d in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#8 0x0000555c958222ce in ?? ()
#9 0x00007f7b9e7861e3 in __libc_start_main (main=0x555c95821b50, argc=6, argv=0x7fffbeb91c18, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffbeb91c08) at ../csu/libc-start.c:308
#10 0x0000555c9582249e in ?? ()

or

Thread 1 (Thread 0x7f7b9d98af00 (LWP 27599)):
#0 0x00007f7b9f1e8b83 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#1 0x00007f7b9f1e8be2 in gdk_x11_display_error_trap_push () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#2 0x0000555c9582e33a in ?? ()
#3 0x0000555c95834f1b in ?? ()
#4 0x0000555c958337d0 in ?? ()
#5 0x00007f7b9f1f0f4f in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#6 0x00007f7b9f1f133a in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#7 0x00007f7b9f1b9094 in gdk_display_get_event () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#8 0x00007f7b9f1f0fe6 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#9 0x00007f7b9ee7484d in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007f7b9ee74ad0 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007f7b9ee74dc3 in g_main_loop_run () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007f7b9f4d2c2d in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#13 0x0000555c958222ce in ?? ()
#14 0x00007f7b9e7861e3 in __libc_start_main (main=0x555c95821b50, argc=6, argv=0x7fffbeb91c18, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffbeb91c08) at ../csu/libc-start.c:308
#15 0x0000555c9582249e in ?? ()

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: xfwm4 4.14.0-1
ProcVersionSignature: Ubuntu 5.3.0-26.28-generic 5.3.13
Uname: Linux 5.3.0-26-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu8.4
Architecture: amd64
CurrentDesktop: XFCE
Date: Mon Feb 24 23:18:34 2020
InstallationDate: Installed on 2019-01-21 (399 days ago)
InstallationMedia: Xubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2)
SourcePackage: xfwm4
UpgradeStatus: Upgraded to eoan on 2019-11-10 (106 days ago)

Revision history for this message
Shevek (r-launchpad-anarres-org) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xfwm4 (Ubuntu):
status: New → Confirmed
Revision history for this message
John Morris (1pt1nq88tvxvjiijcixknc4iaqh3-na9c-8aho930n7szvk8tyqp2yd0cny5gr) wrote :

The `gdk_x11_display_error_trap_push` symbol in the above stack trace indicates it's the upstream bug described in the following issue, and fixed by the patch in the referenced comment:

https://gitlab.xfce.org/xfce/xfwm4/-/issues/351#note_13692

The problem is confirmed present in the current Focal package source, xfwm4 v. 4.14.1.

Revision history for this message
John Morris (1pt1nq88tvxvjiijcixknc4iaqh3-na9c-8aho930n7szvk8tyqp2yd0cny5gr) wrote :

@shevek Nice call on the "leaking something?". You nailed it.

Revision history for this message
Shevek (r-launchpad-anarres-org) wrote :

Oh, goody. Ironically, I had figured out that it was the compositor, too, because repeatedly zooming and unzooming caused it to get worse faster. What do we have to do to get this into bionic and focal?

Revision history for this message
Sean Davis (bluesabre) wrote :

Fixed in Xfwm 4.14.5

Changed in xfwm4 (Ubuntu Focal):
status: New → Confirmed
Changed in xfwm4 (Ubuntu Groovy):
status: New → Fix Released
Sean Davis (bluesabre)
description: updated
Revision history for this message
Sean Davis (bluesabre) wrote :

Attaching debdiff for xfwm4_4.14.5-1ubuntu0.20.04.1, also uploaded to the Xubuntu SRU Staging PPA:

https://launchpad.net/~xubuntu-dev/+archive/ubuntu/sru-staging

Sean Davis (bluesabre)
Changed in xfwm4 (Ubuntu Focal):
status: Confirmed → In Progress
assignee: nobody → Sean Davis (bluesabre)
Revision history for this message
Robie Basak (racb) wrote :

These three bugs look appropriate to SRU. Thank you for working on them!

I see that the uploads in the queue are for upstream microreleases, rather than cherry-picks. This is also fine, but only if the requirements are met as documented at https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases.

However I see no documentation about how xfwm4 upstream meets the requirements or if they do at all. Please could you provide further information on this?

Revision history for this message
Sean Davis (bluesabre) wrote :

Xfwm4 has CI configured to run tests on every commit. For non-translation commits, build and distcheck jobs are run.

https://gitlab.xfce.org/xfce/xfwm4/-/pipelines

As 4.14.2-4.14.5 are all bug fix releases, I would recommend the 4.14.5 release instead of individual cherry-picks in between. This would bring Focal up to the same package version as Groovy and not miss out on some of the more obscure bugs that we opt not to cherry-pick.

Revision history for this message
Robie Basak (racb) wrote :

That only half answers my question. Are *all* the requirements from https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases met, and if so, how?

Revision history for this message
Sean Davis (bluesabre) wrote :

They are not, only the automated CI build process for each commit and release. Is it possible to get an exception, or do we need to instead do one of:

- Cherry-pick the individual big fixes
- Create LP bugs for every fix included between those releases

My concern is that having a pulling in individual commits creates a version of Xfwm that doesn’t otherwise exist and is only supported by Xubuntu and not the upstream. It also leads to more work later if any of the unincluded bug fixes need to be fixed later.

Revision history for this message
Robie Basak (racb) wrote :

The policy says:

"In other cases where such upstream automatic testing is not available, exceptions must still be approved by at least one member of the Ubuntu Technical Board."

So yes, you can ask for an exception. If you want to do that, I suggest that you point technical-board@ at this bug.

> ...or do we need to instead do one of...

I think you'd need to do both of what you have listed there. You might want to pick the most important fixes to cherry-pick, rather than all of them.

> My concern is that having a pulling in individual commits creates a version of Xfwm that doesn’t otherwise exist and is only supported by Xubuntu and not the upstream. It also leads to more work later if any of the unincluded bug fixes need to be fixed later.

You're certainly not the only one who has made this argument. Note though that this concern applies equally to *any* package being updated under this Ubuntu policy. In effect, you're saying that you disagree with the policy in principle, rather than presenting a specific case for why the policy should be set aside for you in this particular case due to some exceptional circumstance.

You're entitled to disagree with Ubuntu policy, and discussion to change the policy if it is no longer appropriate is also welcome. But if the project were to agree with you on this specific concern, then I think it would make sense to change the policy itself rather than grant an exception on the basis of this specific argument. Doing otherwise would be a contradiction of the policy itself.

There is a separate question here of what to do where automated tests are difficult or don't make sense, as is the case I think with a GUI. Maybe an exception could be discussed on this basis, or even a general policy exception for GUIs.

I would like to point out that you're not being blocked from fixing this bug pending further discussion here. If fixing this bug soon is important to you, you can just cherry-pick the fix using the normal SRU process.

Mathew Hodson (mhodson)
Changed in xfwm4 (Ubuntu):
importance: Undecided → Medium
Changed in xfwm4 (Ubuntu Focal):
importance: Undecided → Medium
Changed in xfwm4 (Ubuntu Groovy):
importance: Undecided → Medium
Changed in xfwm4 (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

I see this upload is present in the SRU queue for quite a while. As Robie disagreed with accepting it as is, this is currently blocked until further action is performed and our hands are tied. Is this still being worked on? What is the status?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.