appimagelauncherd.service triggering memory leak in gnome-shell

[colinl]

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.