appimagelauncherd.service triggering memory leak in gnome-shell

[colinl]

trafficstars

Running AppImageLaucher 2.1.1 on Ubuntu 19.10, installed from appimagelauncher_2.1.1-travis931.f6d5926.bionic_amd64.deb, if appimagelauncherd is running then gnome-shell exhibits a memory leak of several MB/minute, but only if the Move To directory is set to a non-standard setting.

I think that almost certainly this is related to Issue #294 which also only exhibits itself when the destination directory is changed.

See associated gnome-shell issue https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1862910

To Reproduce Steps to reproduce the behaviour:

1. Running Ubuntu 19.04 logged on with 'Ubuntu' session (ie gnome-shell) install AppImageLaucher from appimagelauncher_2.1.1-travis931.f6d5926.bionic_amd64.deb
2. Run AppImageLauncher
3. Set the Move To directory to apps/appimages under your home directory
4. Install an AppImage (I installed Cura, but actually I don't know whether it is necessary to install one at all).
5. Monitor the memory usage of gnome-shell in System Monitor (for example). The leak may take a few minutes to get going then it will increase until all memory is used up.
6. Stop the daemon from running and the memory leak ceases.

Tested with both v2.1.0 and 2.1.1

I guess this is AppImageLauncher doing something unusual which then triggers the leak in gnome-shell. The clue to diagnosing may be the fact that it does not appear if the destination directory is left unspecified.

[TheAssassin]

Possibly related to #294.

Have you reported the bug to Ubuntu/GNOME yet?

[colinl]

Yes, I posted the link in the description https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1862910 In fact it was trying to track down that bug that I realised eventually that it only happened when the AppImageLauncher daemon was running. It was not at all the sort of trigger I was expecting.

[TheAssassin]

Hm. The behavior you and #294 describe is really strange. What I can't believe is that it only occurs whenever the directory is changed. This is very strange.

What directory have you set it to?

[colinl]

I agree it is very strange, but definitely true, I have confirmed it on two separate machines. I have set it to /home/<me>/apps/appimages.

[TheAssassin]

I'm not arguing that bug doesn't exist. It's just that changing a single option seems to trigger it.

Going to boot a VM running a vanilla Ubuntu Desktop ISO. Let's see if I can reproduce the issue therein.

[TheAssassin]

I've had a VM running with the same directory and two AppImages for 20 minutes now, and I don't see any memory leak. Can you please try the same, but with all your AppImages? This seems like a problem with something nonstandard you installed...

Also what process exactly eats up all your memory?

[TheAssassin]

I've had the VM running in the background, and just rediscovered it. It seems like it got stuck, perhaps due to your mem leak. I'm going to try to reproduce the problem now again, with better monitoring.

[colinl]

I am in the process of building a VM to try it (I haven't used VMs before, at least not for 15 years and it has all changed rather). It is the process gnome-shell that grows. It starts at about 130MB and grows from there. Not very obviously in the first 5 minutes or so but then at several MB/min. Do please post if you do find a problem to save me the time in reproducing it again.

[TheAssassin]

Current state in my new VM. The last VM has been running fine for ~48 minutes, too, until I forgot about it. Let's see what happens.

[colinl]

In htop, for gnome-shell, my machine (not the VM) started at Virt 2875, Res 209 and after 20 minutes it is now at Virt 2964, Res 300.

[TheAssassin]

Another hour later, it uses around 250MiB more RAM. appimagelauncherd is running in the background, but we cannot be fully sure it's caused by the daemon. But it certainly uses more RAM now.

[colinl]

If you disable the daemon, log out and back in again and monitor it again I think you will find the gnome-shell memory does not grow significantly.

[TheAssassin]

I'll let that run for another while, then will try that out. Hopefully logging out and in works in a live ISO environment as expected.

[colinl]

Not sure if that works in a live image. I think if you just do killall -9 gnome-shell it will restart itself, to save logging out.

[colinl]

Some more input. If I manually enter /home/me/Applications in the destination directory and add the appimage then I still see the problem, however if I delete the destination directory entry in the dialog so that it defaults to /home/me/Applications and re-add the appimage then I do not see the problem.

[TheAssassin]

I simply stopped appimagelauncherd now, and the memory leak seems to have stopped:

So, it seems appimagelauncherd is triggering the leak indeed. I have no idea how. But it must be some problem inside gnome-shell.

[colinl]

Is it possible the s/w is repeatedly registering the appimage when the directory is specified manually, or something like that?

[colinl]

I notice that with a manually entered directory for the destination that appimagelauncherd writes 8kB to disc (as seen in System Monitor) every 30 seconds, whereas if I empty the destination folder field in the dialog then it does not do those writes. That might be a clue as to what is going on, since I assume that there should be no difference between the two situations.

[TheAssassin]

You can check the logs, it's not reintegrating if not necessary.

I wonder why it would be writing every 30 seconds. As noted in #294 every 30 seconds it checks for new locations that need to be monitored. But it doesn't have to write on disk for that, it only has to read from disk to accomplish that.

[colinl]

I have looked in /var/log/syslog and find some things that I do not understand. If I startup with /home/me/apps/appimages as the destination, and daemon enabled then I see

Feb 19 13:59:55 tigger appimagelauncherd[5549]: Searching for existing AppImages
Feb 19 13:59:55 tigger appimagelauncherd[5549]: Searching directory: /home/colinl
Feb 19 13:59:56 tigger appimagelauncherd[5549]: Searching directory: /home/colinl/apps/appimages
Feb 19 13:59:56 tigger appimagelauncherd[5549]: Found AppImage: /home/colinl/apps/appimages/Ultimaker_Cura-4.4.1_2baf12a636cb3a72dbbdd1fb57afe251.AppImage
Feb 19 13:59:56 tigger appimagelauncherd[5549]: AppImage integrated already, skipping
Feb 19 13:59:56 tigger appimagelauncherd[5549]: Watching directories: /home/colinl /home/colinl/apps/appimages
Feb 19 13:59:56 tigger appimagelauncherfs[5551]: Registered new AppImage: "/home/colinl/apps/appimages/Ultimaker_Cura-4.4.1_2baf12a636cb3a72dbbdd1fb57afe251.AppImage" (ID: 0000)
Feb 19 13:59:56 tigger appimagelauncherfs[5551]: mountpoint: /run/user/1000/appimagelauncherfs/
Feb 19 13:59:56 tigger appimagelauncherfs[5551]: Starting FUSE filesystem
Feb 19 14:00:25 tigger appimagelauncherd[5549]: Directories to watch disappeared, unintegrating AppImages formerly found in there
Feb 19 14:18:46 tigger appimagelauncherfs[5551]: Error: could not find registered AppImage: /.Trash
Feb 19 14:18:46 tigger appimagelauncherfs[5551]: Error: could not find registered AppImage: /.Trash-1000

so it says that it is watching my home directory as well as apps/appimages which does not seem right. Also the final messages about disappeared directories and looking at the .Trash folders does not seem right. Is it actually monitoring the whole of my home directory or is the log misleading?

[TheAssassin]

No, it looks like it's really monitoring your $HOME. IIRC we only monitor the first level, though, so that shouldn't be causing performance issues. If anything, you'd expect the daemon process to require more memory.

Nevertheless it's a bug that should be fixed. Please open a new issue.

[roadkell]

I've had the same issue recently (gnome-shell going from ~200 MB post-boot to ~2.5 GB in a couple of hours), and this answer was the solution. It turns out, ~/.config/appimagelauncher.cfg is indeed refreshed frequently when "Auto start auto-integration" tick is on, and the location is set to a non-default directory. Disabling the daemon fixes the issue. UPD: at first, it seemed that unticking the auto-integration option was enough, but it wasn't.

[gamedevsam]

Any update on this issue? Seems concerning.