gnome-shell leaking memory when a customized AppImageLauncher is running

Bug #1862910 reported by Colin Law on 2020-02-12
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gnome-shell (Ubuntu)
Low
Unassigned

Bug Description

Edited description:
To replicate the problem (on Ubuntu 19.10 running Ubuntu Gnome)
1. Install AppImageLauncher from https://github.com/TheAssassin/AppImageLauncher/releases by downloading version 2.1.0 deb file (appimagelauncher_2.1.0-travis897.d1be7e7.bionic_amd64.deb) and install it. If necessary run
sudo apt install -f
to fix missing dependencies.

2. Run it and change the appimage destination location to ~/apps/appimages. It is necessary to change it away from the default setting in order for the problem to appear, though probably the actual destination is not important). Ensure that Auto start auto-integration daemon is selected.

3. Download an appimage (I downloaded Cura 4.4.1 from https://github.com/Ultimaker/Cura/releases/tag/4.4.1) I don't know whether any appimage would do, probably it would. In fact I don't know whether this step and the next need to be done at all.

4. Open it with appimagelauncher (this can be done by double clicking it in nautilus) and tell it to move it and run the application. Then close the application.

5. It may be necessary to reboot at this point I don't know.

6. Logon using Ubuntu (Gnome) and watch the memory usage of gnome-shell. It may take a few minutes to get going but then the memory used will start increasing at several MB/minute.

There is an issue open against appimage launcher which is likely the same problem. https://github.com/TheAssassin/AppImageLauncher/issues/294

Original description:
On one of my machines which has been upgraded over several years and
is now running 19.10 just one of the configured users appears to be
seeing a dramatic memory leak in gnome-shell, even when nothing is
happening on the UI. Immediately after logging on, using the Ubuntu
selection from the logon screen, gnome shell shows as using about
134MB. From there it climbs at about 300MB per hour and after a few
hours the machine grinds to a crawl, not surprisingly. This happens
even if the user logs on and then the machine is left completely
alone. Logout and back in frees all the memory.
A test user I have configured sees no such problem.
I have uninstalled all extensions apart from the system ones, disabled
all the system ones and reset all the gnome settings using dconf reset
-f /org/gnome/ to no avail. Also I have removed
~/.local/share/gnome-shell and allowed it to recreate it.
Also I have removed .compiz, .config/dconf/user, .gconf, .gnome, .gnome2.
I can't see anything obvious in the log.
It must be something in my settings that is triggering it as the other
user does not see it, but I have run out of ideas on what to try.

See also bug #1856516

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: gnome-shell 3.34.1+git20191024-1ubuntu1~19.10.1
ProcVersionSignature: Ubuntu 5.3.0-29.31-generic 5.3.13
Uname: Linux 5.3.0-29-generic x86_64
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Feb 12 08:54:21 2020
DisplayManager: gdm3
InstallationDate: Installed on 2014-10-21 (1939 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Alpha amd64 (20141017)
RelatedPackageVersions: mutter-common 3.34.1+git20191107-1ubuntu1~19.10.1
SourcePackage: gnome-shell
UpgradeStatus: Upgraded to eoan on 2020-01-27 (15 days ago)

Colin Law (colin-law) wrote :
Daniel van Vugt (vanvugt) wrote :

I would like to understand if there's something about your system triggering these leaks that most of us don't encounter.

Please:

1. Take a screenshot of your whole Ubuntu desktop (all monitors) that is experiencing the problem and attach it here.

2. Try setting this to false:

   b'org.gnome.desktop.interface' b'clock-show-seconds' b'true'

   and run the leak test again.

3. Try disabling ALL Ubuntu extensions, or just try a raw GNOME session which should be the same:

   sudo apt install gnome-session

   and choose GNOME on the login screen.

Changed in gnome-shell (Ubuntu):
status: New → Incomplete
Daniel van Vugt (vanvugt) wrote :

I would also like to know more about your GPU/driver configuration, in case the problem is unique to a particular driver.

Please run:

  lspci -k > lspcik.txt

and attach the resulting file here.

Please also run:

  sudo apt install mesa-utils
  glxinfo > glxinfo.txt

and attach the resulting file here.

Colin Law (colin-law) wrote :

1. Screenshot attached. I have been using two screens but to simplify things I have confirmed that only having one makes no difference, so I am sticking to that whilst testing.

2. I did already have show seconds set, I have now tried without and it doesn't seem to make a difference

3. I thought I had disabled all extensions, though I am not entirely sure of the official method of doing that. If I go to https://extensions.gnome.org/local/ I see only Desktop Icons, Ubuntu App Indicators and Ubuntu Dock and they are all disabled, but as you can see from the screenshot I don't see exactly the same as I see if I logon using Gnome. For instance the Dock is not autohiding. So I don't know what is going on there. Logging on using Gnome does not stop the leak though.

I see I have a larger selection of logon options than I see in a clean install, I have Gnome, Gnome Classic, Gnome on Xorg, Ubuntu, Ubuntu on Wayland, and Unity. I tried them all a few days ago and they all exhibited the leak except Gnome Classic and Unity, though I have done a lot of cleaning up trying to fix the problem since then so if it would be useful I can repeat that test.

Colin Law (colin-law) wrote :
Colin Law (colin-law) wrote :
Colin Law (colin-law) wrote :

I think this may not be a gnome-shell issue at all. I installed appimagelauncher [1] some time ago and if I disable the daemon and reboot then it seems the memory leak is no more. At least I think that is the case, I need to do some more testing but thought I should report back immediately so that no-one wastes any more time on it.
I will follow up when I have reached a firm conclusion.

[1] https://github.com/TheAssassin/AppImageLauncher

Daniel van Vugt (vanvugt) wrote :

> I installed appimagelauncher [1] some time ago and if I disable the daemon and reboot then it seems the memory leak is no more.

Yes, please verify that. It's hard to imagine how that's relevant to gnome-shell's memory usage, but one theory is that it is periodically triggering code execution in gnome-shell that a default system would not experience. This could happen via dbus interfaces, or by repeatedly changing the set of installed apps. That would still be a gnome-shell bug, but not a common one...

> I did already have show seconds set, I have now tried without and it doesn't seem to make a difference

Can you please check that again, without show-seconds? That was my strongest suspicion of why the leak continues on a desktop that's not being used.

Daniel van Vugt (vanvugt) wrote :

BTW, show-seconds also causes CPU spikes and frame stutters, so best to avoid that for now.

https://gitlab.gnome.org/GNOME/gnome-shell/issues/2085

Colin Law (colin-law) wrote :

I had initially misunderstood which way round you wanted me to check with the seconds setting, but I had checked carefully both ways and have now checked again that I cannot see any discernable leakage with seconds enabled, but I have got it disabled now.

I have also confirmed without doubt that it is appimagelauncher daemon that is triggering the problem. With it disabled there is no apparent leakage and with it enabled there is. However, rather irritatingly, I have been unable to replicate this on another machine, so there must be some additional interaction on the failing system. Currently I have no idea what that might be.

Colin Law (colin-law) on 2020-02-13
summary: - gnome-shell leaking memory
+ gnome-shell leaking memory in interaction with appimagelauncher

I have managed to replicate it on another system, it was necessary to change the destination location away from the default in appimagelauncher for the problem to appear. I have updated the description above with detailed procedure for replicating.

There is already an open issue against appimagelauncher which is most likely related.
https://github.com/TheAssassin/AppImageLauncher/issues/294

description: updated
description: updated
Changed in gnome-shell (Ubuntu):
status: Incomplete → New
Daniel van Vugt (vanvugt) wrote :

Thanks for that investigation. It's not completely clear to me that upstream bug 294 is/was about leaks. Maybe you should open a new one?

  https://github.com/TheAssassin/AppImageLauncher/issues

summary: - gnome-shell leaking memory in interaction with appimagelauncher
+ gnome-shell leaking memory when a customized AppImageLauncher is running
Changed in gnome-shell (Ubuntu):
importance: Undecided → Medium
tags: added: leak
Changed in gnome-shell (Ubuntu):
importance: Medium → Low
Colin Law (colin-law) wrote :

I have opened a new issue on AppImageLauncher.
https://github.com/TheAssassin/AppImageLauncher/issues/301

no longer affects: appimagelauncher
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-shell (Ubuntu):
status: New → Confirmed
tags: added: gnome-shell-leak
removed: leak
Daniel van Vugt (vanvugt) wrote :

Thank you for reporting this bug to Ubuntu.
Ubuntu 19.10 (eoan) reached end-of-life on July 17, 2020.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in.

Changed in gnome-shell (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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