Ubuntu
xfwm4 package

xfwm4 very, very slow - leaking something?

Bug #1864613 reported by Shevek on 2020-02-25

This bug affects 3 people

	Status	Importance	Assigned to
Xfwm4	Fix Released	Unknown	auto-gitlab.xfce.org-xfce-xfwm4-- #351
xfwm4 (Ubuntu)	Fix Released	Medium	Unassigned
Focal	In Progress	Medium	Sean Davis
Groovy	Fix Released	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 ?? ()

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)

See original description

Tags:

Revision history for this message

Shevek (r-launchpad-anarres-org) wrote on 2020-02-25:

Dependencies.txt Edit (4.6 KiB, text/plain; charset="utf-8")
ProcCpuinfoMinimal.txt Edit (1.3 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (103 bytes, text/plain; charset="utf-8")

Revision history for this message

Launchpad Janitor (janitor) wrote on 2021-01-22:

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 on 2021-01-22:

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 on 2021-01-22:

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

Revision history for this message

Shevek (r-launchpad-anarres-org) wrote on 2021-03-14:

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 on 2021-04-06:

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) on 2021-04-06

description:

updated

Revision history for this message

Sean Davis (bluesabre) wrote on 2021-04-06:

xfwm4 debdiff Edit (452.8 KiB, text/plain)

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) on 2021-04-06

Changed in xfwm4 (Ubuntu Focal):
status:	Confirmed → In Progress
assignee:	nobody → Sean Davis (bluesabre)

Revision history for this message

Robie Basak (racb) wrote on 2021-04-07:

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 on 2021-04-07:

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 on 2021-04-08:

#10

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 on 2021-04-08:

#11

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 on 2021-04-15:

#12

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.

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.

Mathew Hodson (mhodson) on 2021-04-23

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 on 2021-08-05:

#13

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?

Revision history for this message

Brian Murray (brian-murray) wrote on 2021-12-14: Proposed package upload rejected

#14

An upload of xfwm4 to focal-proposed has been rejected from the upload queue for the following reason: "This is a mircorelease update of xfwm4 that doesn't follow the policy.".

Revision history for this message

Shevek (r-launchpad-anarres-org) wrote on 2022-03-04:

#15

This is:
* a significant memory leak
* causing me to have to restart Xorg every couple of days
* in the current LTS release
* reported over 2 years ago, and
* for which a fix is available.

Can we PLEASE get it in? Thank you.

Bug Watch Updater (bug-watch-updater) on 2022-05-20