gnome-shell leaks hundreds of megabytes when the dock option 'show-trash' is enabled.

[Robert]

Gnome shell is the single largest resident memory user on my system.

It was hovering at ~700mb, then with a few minutes of use of the system (nothing in particular, mostly shell windows, one google-chrome window) - spiked to ~980mb or so, before retreating to 903m.

Even with 16gb of ram, that's a huge chunk of the system.

I've not been able to identify anything in particular that I'm doing that triggers the growth.

In https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1856838/comments/5, it was suggested to open a new bug, instead of adding to one of the several existing bugs for this. I'm happy to help try and debug this, but it's not clear where to start.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gnome-shell 3.36.1-5ubuntu1
ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
Uname: Linux 5.4.0-26-generic x86_64
ApportVersion: 2.20.11-0ubuntu27
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Sun May 3 17:32:52 2020
DisplayManager: gdm3
InstallationDate: Installed on 2018-11-18 (532 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
RelatedPackageVersions: mutter-common 3.36.1-3ubuntu3
SourcePackage: gnome-shell
UpgradeStatus: Upgraded to focal on 2020-04-18 (15 days ago)

[Daniel van Vugt (vanvugt)]

Please:

1. Uninstall any non-Ubuntu extensions. We need to test this first since so many bugs are caused by extensions.

2. Provide a screenshot confirming you're talking about RSS and not talking about the VSIZE of the process.

[Daniel van Vugt (vanvugt)]

I am setting this bug to Private to ensure it doesn't get clouded by unrelated "me too" comments, as bugs like this often do. You can still add comments yourself.

[Robert (rspier)]

Screenshot attached.

```
top - 19:50:31 up 8 days, 2:55, 2 users, load average: 1.59, 0.90, 0.73
Tasks: 493 total, 1 running, 490 sleeping, 1 stopped, 1 zombie
%Cpu(s): 4.0 us, 1.5 sy, 0.0 ni, 93.2 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st
MiB Mem : 15929.1 total, 942.6 free, 5477.2 used, 9509.2 buff/cache
MiB Swap: 976.0 total, 0.1 free, 975.9 used. 8733.5 avail Mem

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
   4944 rspier 20 0 6416656 975476 443564 S 3.9 6.0 57:04.97 gnome-shell
1598591 rspier 20 0 5009456 442020 145216 S 0.0 2.7 48:36.29 chrome
```

[Robert (rspier)]

I've disabled all extensions that don't have "Ubuntu" in the name. (I'd really like to re-enable Horizontal workspaces, which I think is core, as well as add and enable a working appindicator plugin.)

[Daniel van Vugt (vanvugt)]

Thanks. Now that you have removed the non-Ubuntu extensions please:

1. Log out and log in again.

2. Run this command:

   gsettings list-recursively org.gnome.shell > settings.txt

   and attach the resulting file here.

3. Tell us if the problem returns and if so then attach another screenshot.

[Robert (rspier)]

Attaching settings.txt as requested in #6

[Robert (rspier)]

After a few days, there's evidence that the leak was extension related: Memory usage didn't explode.

Since bug 1718850 was preventing me from using the core indicator extension, I'm turning back on Ubuntu Appindicators and Horizontal Workspaces to see what happens. If the leak returns, I'll turn off one of them.

[Robert (rspier)]

Good news / bad news / weird news:

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1950373 rspier 20 0 10.3g 5.6g 169.2m S 3.6 36.2 14:46.00 gnome-shell

Since yesterday, and re-enabling the Horizontal workspaces and Ubuntu AppIndicators extensions in gnome-shell-extension-prefs, we seem to have blown up memory usage.

Also interesting is that those extensions are no longer listed as active in gnome-shell-extension-prefs. I'm confident I didn't deactivate them.

settings.txt from today attached.

[Robert (rspier)]

Horizontal workspaces and Ubuntu AppIndicators no longer active. Screenshot attached.

$ gnome-extensions list --enabled
desktop-icons@csoriano
<email address hidden>

[Robert (rspier)]

I'll attempt to leave gnome-shell in this state for a little, but may have to restart it in a few hours.

[Robert (rspier)]

I ended up having to restart it. But I put in place some monitoring. I'm still waiting for another giant spike... but the memory usage is already interesting: There are some pretty significant RSS changes going on when the screen has been locked for hours.

[Daniel van Vugt (vanvugt)]

Please try _uninstalling_ all extensions. Don't just disable them. Because in the past we've found that buggy extensions can still affect the shell.

[Daniel van Vugt (vanvugt)]

Please also try scale 100% for a while to see if that helps.

[Robert (rspier)]

Set scale to 100% at 5/11 9:40am PDT.

There are no extensions in .local/share/gnome-shell.

Do you want me to uninstall the .debs too ?

[Daniel van Vugt (vanvugt)]

Yes, please do uninstall the extensions' debs. Then reboot and run without extensions (other than Ubuntu's) and at 100% for a while. Also run gnome-shell-extension-prefs to verify they are gone.

Any improvement?

[Robert (rspier)]

Memory usage definitely changed drastically turning off scaling.

On the down side, the system is nearly unusable because everything is tiny now.

[Robert (rspier)]

Ok. I've removed the gnome-shell-extensions deb.

The only extensions remaining are

Desktop Icons
Ubuntu Appindicators
Ubuntu Dock

Rebooted, and will report back after it has time to cook for a while.)

[Robert (rspier)]

Sooner than expected...

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
   4354 rspier 20 0 5448496 817808 99060 S 9.2 5.0 0:34.84 gnome-shell

Windows open:
 1 each of google-chrome, gnome-terminal, gnome-shell-extension-prefs

[Robert (rspier)]

A few minutes later, adding a nautilus window... and another two gnome-terminals.

   4354 rspier 20 0 6515320 1.8g 115124 S 7.0 11.7 1:12.01 gnome-shell

[Daniel van Vugt (vanvugt)]

Interesting. For me a day working in gnome-shell doesn't see it grow any bigger than 190MB. So I would like to figure out what's different about your machine...

1. Please run:

   lspci -k > lspcik.txt
   journalctl -b0 > journal.txt

   and then attach the resulting two text files.

2. Does your background wallpaper change, or is it the same all day?

3. Please try a day with Wayland and a day with Xorg and tell us if there's any difference in results.

4. Are you still using display scaling? If so then what values? And is that in Xorg or Wayland?

[Robert (rspier)]

Trying again without gnome-shell-extension-appindicator package.

[Robert (rspier)]

lspci -k

[Robert (rspier)]

1. The journalctl output has a bit more information about unrelated things than I'd like to share. Is there something in particular you're interested in that I can filter it down to?

2. It's the same all day.

3. Xorg is slow on this older machine with a 4K display using the built in Intel i915 graphics. So I've been using Wayland. I can try Xorg again.

4. Display scaling is currently off. It was previously set to 125%.

$ gnome-extensions list
desktop-icons@csoriano
<email address hidden>

Are you using AppIndicators? I'd like to re-enable them. (Primarily for the insynchq.com indicator.)

It's interesting that you're not seeing it larger than 190MB. Mine starts at ~260MB.

[Robert (rspier)]

Could actions in Nautilus trigger memory usage in gnome-shell?

It seems that I may have triggered a 500MB RSS increase by deleting several directories in nautilus. The memory allocation is so aggressive the system freezes for several seconds immediately after I select delete from the menu.

I was just able to repeat this

cd Downloads
touch a b c d e f
# in nautilus, select them, right click, choose Move to Trash

memory usage jumped 200 MB.

use looking glass to force a gnome-shell GC (no memory is freed)

touch a b c d e f g h i j k l m n o p q r s t u v
# delete via nautilus

now I'm up another 2.2 g of usage ( to 3.2g)

[Daniel van Vugt (vanvugt)]

Oh yes, I forgot to mention I have zero extensions enabled. I will have to try some days with them re-enabled. And you please try some days with zero, or just one. If would be great if we could both confirm which if any extension is to blame.

Also do you see the desktop icons flash when you move things to the trash? I think that extension might be a good place to start. And maybe try disabling "Show the trash icon in the desktop" under gnome-shell-extension-prefs.

[Robert (rspier)]

Aha!

I can replicate the Nautilus deletion issue in Xorg.

I've removed all extensions from my system except for <email address hidden>.

If Ubuntu Dock is enabled -- nautilus deletion is slow and leak.
If Ubuntu Dock is NOT enabled -- nautilus deletion is fast and NO leak.

(The system has a SSD, and I'm testing with zero byte files, so it's not an obvious IO issue.)

[Daniel van Vugt (vanvugt)]

Unfortunately I can't confirm that. Following the steps from comment #25 with all Ubuntu extensions loaded I get no slowness and no measurable leak!

Are you able to share a screenshot of your dock and desktop icons? Clearly there's still something I am missing.

[Daniel van Vugt (vanvugt)]

I wonder if you have this hidden setting enabled... try disabling it then log out and in again:

  gsettings set org.gnome.shell.extensions.dash-to-dock show-trash false

[Robert (rspier)]

Great news:

No leak: gsettings set org.gnome.shell.extensions.dash-to-dock show-trash false
Leak: gsettings set org.gnome.shell.extensions.dash-to-dock show-trash true

turning it off and logging out/in also reduces initial gnome-shell memory use to ~170mb.

[Robert (rspier)]

Desktop Icons extension with "Show the trash icon in the desktop" does not appear to trigger the issue.

[Daniel van Vugt (vanvugt)]

Thanks! Now that's clarified we can make this bug public again.

[Amr Ibrahim (amribrahim1987)]

I also have the trash shown on the dock, and gnome-shell is consuming 559 MB of memory.

[Daniel van Vugt (vanvugt)]

Amr,

Please check that this command fixes the problem:

  gsettings set org.gnome.shell.extensions.dash-to-dock show-trash false

after logging out and in again. If the leak still happens then please don't comment here, but open a new bug by running:

  ubuntu-bug gnome-shell

[Daniel van Vugt (vanvugt)]

'show-trash' is enabled by default and we're still getting reports of the leak in impish so I think this bug should be queued.

[Daniel van Vugt (vanvugt)]

I can't see any growth in memory usage on 22.04 when stressing everything related to the trash icon. Although I haven't tried waiting multiple hours and I haven't tried an older Ubuntu release yet. (I don't use the dock on my own desktops)

Can anyone reproduce it in 22.04? http://cdimage.ubuntu.com/daily-live/current/

Can anyone suggest a test case that accelerates the leak?

[Erik Meitner (e.meitner)]

This problem is affecting my laptop. It gets to the point where the system starts thrashing so badly I care barely get to the console and log in to start killing processes.

Ubuntu 20.04
gnome-shell 3.36.9-0ubuntu0.20.04.2

$ uname -a
Linux cherna 5.4.0-96-generic #109-Ubuntu SMP Wed Jan 12 16:49:16 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Just now:
$ pidstat -l -r|egrep 'UID|/usr/bin/gnome-shell'
10:34:32 AM UID PID minflt/s majflt/s VSZ RSS %MEM Command
10:34:32 AM 1000 3659 83.54 0.15 7330020 1768040 11.13 /usr/bin/gnome-shell

It happens around once a week depending on my usage of the laptop which is my work laptop tat stays on almost all the time. I don't see a pattern to it yet.

At least I can ALT-F2 & "r" to recover some RAM. If I notice the problem in time....

[sammy247 (sammy247)]

@Erik Meitner

Did you try the fix that solved it for me and others - see #34 above

Please check that this command fixes the problem:

  gsettings set org.gnome.shell.extensions.dash-to-dock show-trash false

after logging out and in again. If the leak still happens then please don't comment here, but open a new bug by running:

  ubuntu-bug gnome-shell

[Amr Ibrahim (amribrahim1987)]

I don't want to be this guy, but I think the problem lies in the gnome-shell 3.36 stack. Because after I moved to Debian 11 with gnome-shell 3.38, the memory usage of gnome-shell doesn't go above 200 MB with 6 extensions, 4K resolution and uptime: 1 day, 39 min.

[Daniel van Vugt (vanvugt)]

Bug 1955058 mentions the issue is still present in ubuntu-dock with gnome-shell 40.

[Daniel van Vugt (vanvugt)]

Actually bug 1955058 might have some other explanation. In my own testing I can now reproduce this bug on 20.04 but not 22.04. Although even 22.04 seems to spike 10MB+ temporarily and drops back down after a few seconds.

[Daniel van Vugt (vanvugt)]

This sounds like the first fix for the issue which probably explains why it mostly went away in 20.10:

https://github.com/micheleg/dash-to-dock/pull/1266/commits/a8c0e1ece7b69e893943ab44a561e8ab2979551f

The fix is missing in 20.04 still. But performance of deleting files is still poor even in 22.04 so I'll see what I can do about that before suggesting backports.

[Daniel van Vugt (vanvugt)]

It seems the performance issue in 22.04 only exists in 22.04 (bug 1962699) and not in earlier releases. That means we only need to backport https://github.com/micheleg/dash-to-dock/pull/1266 to fix this bug in 20.04.