Gnome-shell-extension-gsconnect: Memory leak when resuming from suspend/hibernate

[IjonFryderyk]

Hi,
I've experienced memory leak from gjs /home/user/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js. It happens after suspend but not every time. For the first time I noticed it yesterday (I've been using gsconnect for quite a while and I haven't had any problems earlier) and since then it has happened three times. What is happening is that gjs process is constantly increasing the usage of memory (yesterday I killed it when it reached more than 4 GB of ram usage, normally it uses about 23-40 MB). Unfortunately I don't know how to reproduce it. I'm on Ubuntu 18.04 upgraded from 16.04.

[andyholmes]

I've marked this immediately as a confirmed bug, since I don't see how it could be a mistake given your report. I've never experienced this myself, although I don't use suspend and frequently restart the service in the course of development.

I'll try and set aside some time to setup for suspending my machine, but any additional information will be helpful, even if it takes time to put the pieces together.

• Does it only happen in response to suspend
• Is this actually suspend and not hibernate
• Are there any less common hardware or software factors in play (eg, HiDPI, network proxy, multiple monitors, etc)
• Were GSConnect windows open during suspend, or frequently opened and closed during usage (SMS, Settings, etc)
• Is this also true of the Browser extension connector, which you may or may not use (nativeMessagingHost.js)
• For sake of ruling it out, if it happens again can you run free -m to confirm the memory is "used" and not just "cached" (which the kernel can free when it needs to)

[IjonFryderyk]

Today the bug was triggered by this line of events:
I was talking on the phone -> I got out of wifi range -> in meantime laptop suspended -> I stopped talking on the phone -> I woke up my laptop -> memory leak (this time it stopped at about 650 MB usage but I also noticed that gjs process was using 25% of cpu).

1. I think that it does happen in response to suspend.
2. It is suspend not hibernation.
3. I don't know. I don't use any of what you have mentioned.
4. No.
5. I don't use it.
6. Memory is used not cached.

[andyholmes]

Excellent, there's lots of reassuring news in there and good information about how to reproduce. I'm away from home at the moment, but when I get back I'll setup for suspend. I would bet there is something other services do when suspend is about happen.

I have a suspicion this has something to do with networking, or it's related since this has similarities to a bug with some proxies I've been trying to track down. I'll do my best to get a fix, or at least a workaround in for v15 since this is a pretty bad bug under pretty common circumstances.

[andyholmes]

I've set up for suspend, but I haven't yet been able to replicate this. You mentioned it doesn't always happen so I'm going to continue trying to replicate this by leaving suspend enabled on my laptop. BTW, is there any connection between whether you manually suspend, or when it happens automatically?

Since I can't diagnose the problem yet, I'm going to release v15 as planned so that other bug fixes get distributed, but this is still a high priority for the project.

[IjonFryderyk]

Within last 10 days it has happened only two times. It happens after automatic suspend and manual when I close the lid. Unfortunately I don't have any new clue what can be the cause. Maybe it has something to do with some bugs that are affecting me:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-appindicator/+bug/1740600
https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1766137
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1801743
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774950

[andyholmes]

I still haven't been able to reproduce this myself, but it seems kind of rare even for you, and I'm unclear on what happens at the desktop level when suspend happens. Maybe things don't always happen in the same order (maybe not relevant for most applications).

https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1766137

This one is interesting. I'm not sure the _specific_ problem applies, but it got be thinking that maybe it's a DBus connection problem that's causing this. Maybe we need a new one or services don't get the same address after resume. DBus services have thing similar to "domain name->IP address"; we always use the well-known name (org.gnome.Shell.Extensions.GSConnect), but that's just a convenience for the unique address that might be changing.

I've started to have a look at logind which has suspend/hibernate signals that can be watched, the only thing I worry is it might be too systemd specific. Maybe the best thing is to just kill the service on suspend/hibernate since it won't be doing anything anyways.

[IjonFryderyk]

I don't know if it is a useful piece of information but I've noticed that gjs stops accumulating memory after shell restart (alt+f2 and r command).

[andyholmes]

Yes, it may be in fact that all I have to do is shutdown the shell extension, which is a lot easier than the service because the extension's job is to restart the service when it stops. Good catch.

[andyholmes]

Out of curiosity, do you remember if the memory was freed after restart or if it just stopped increasing?

[IjonFryderyk]

Memory is freed after gjs kill. Shell restart only stops the increasing of the leak. I didn't have this problem for a while. Maybe one of the updates solved it.

[andyholmes]

That would be great, I love when that happens!

I hadn't actually figured out a way to do this yet, since apparently extensions are already disabled on suspend. We'll leave this open, and just let me know if it happens again. Otherwise you can close it when you think it's been long enough that it's fixed.