Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1965944 - Leaking X resources (on virtual desktop switch)
Summary: Leaking X resources (on virtual desktop switch)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: marco
Version: 34
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Wolfgang Ulbrich
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-31 08:13 UTC by Jan Kratochvil
Modified: 2021-07-10 01:13 UTC (History)
3 users (show)

Fixed In Version: marco-1.24.2-2.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-07-10 01:13:30 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Jan Kratochvil 2021-05-31 08:13:28 UTC 
Description of problem:
After 3 weeks the system takes seconds to do virtual desktop switch or anything. Xorg takes all the CPU and it is busylooping in:
Thread 1 "Xorg" hit Breakpoint 1, GetXIDRange (client=5, server=<optimized out>, minp=0x7ffeba975b6c, maxp=0x7ffeba975b68) at ../../dix/resource.c:715
715                 if ((res->id < id) || (res->id > maxid))
#0  GetXIDRange (client=5, server=<optimized out>, minp=0x7ffeba975b6c, maxp=0x7ffeba975b68) at ../../dix/resource.c:715

Version-Release number of selected component (if applicable):
marco-1.24.2-1.fc34.x86_64

How reproducible:
Runtime of 3 weeks. I have 24 virtual desktops (3840x2160) and switching between them very often.

Steps to Reproduce:
After 3 weeks the system takes seconds to do virtual desktop switch or anything.

Actual results:
Too slow to use, need to reboot.

Expected results:
Normal responsivity.

Additional info:
Upstream requires to file it downstream: "Link to bugreport of your Distribution (requirement)"

After boot zrestop:
res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier    
0a00000    41    4    2 1686 2248   1181870K     55K 1181926K 11514 marco
2600000    19    6    1   13   92   127387K	 3K 127391K 14352 Mozilla Firefox

After 15 hours of uptime:
res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier    
0a00000    40    4    2 3847 2256   1130430K     55K 1130486K 11514 marco
2600000    27   10    1   19  119   131396K	 4K 131400K 14352 Mozilla Firefox

Pxms is continually increasing by each virtual desktop switch.
Comment 1 Jan Kratochvil 2021-07-09 14:08:26 UTC 
Please backport:
https://github.com/mate-desktop/marco/commit/8f204678be6d888ad1d2904e28af1aa9f2ad8e11
Comment 2 Jan Kratochvil 2021-07-09 14:13:05 UTC 
This regression was introduced by:
commit 6b05da5e49996a2101edfd703dd3f5d91011d726
Author: Victor Kareh <vkareh>
Date:   Mon Oct 14 15:10:13 2019 -0400
    tabpopup: Make workspaces compatible with OSD popup
 = v1.23.2
Which was during F-32:
  https://bodhi.fedoraproject.org/updates/FEDORA-2020-54716beebb
  marco-1.23.2-1.fc32
Comment 3 Victor Kareh 2021-07-09 15:08:03 UTC 
@jan.kratochvil - I've cherry-picked to 1.24: https://github.com/mate-desktop/marco/commit/76da06f80107bd554f22be3dfe6798a35dc1bb83
Comment 4 Jan Kratochvil 2021-07-09 16:54:42 UTC 
That should be fine, what information should I give?
I am currently using my scratch build and it is fine:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=71471203
 18:54:16 up 1 day, 22:52,  1 user,  load average: 0.18, 0.39, 0.49
xrestop - Display: localhost:0
          Monitoring 29 clients. XErrors: 0
          Pixmaps: 1728206K total, Other:     107K total, All: 1728313K total
res-base Wins  GCs Fnts Pxms Misc   Pxm mem  Other   Total   PID Identifier    
0a00000    43    4    2   56 2380   1229408K     58K 1229466K 11489 marco
2a00000    60   26    1   53  266   350750K	 9K 350759K 16081 Mozilla Firefox
...
Comment 5 Fedora Update System 2021-07-09 20:38:16 UTC 
FEDORA-2021-2bebf0804e has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-2bebf0804e
Comment 6 Wolfgang Ulbrich 2021-07-09 20:39:29 UTC 
Feel free to leave karma for https://bodhi.fedoraproject.org/updates/FEDORA-2021-2bebf0804e
Comment 7 Fedora Update System 2021-07-10 01:04:05 UTC 
FEDORA-2021-f846309b0e has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-f846309b0e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-f846309b0e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 8 Fedora Update System 2021-07-10 01:13:30 UTC 
FEDORA-2021-2bebf0804e has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.