Help test memory leak fixes in 18.04 LTS

There has been a widely reported memory leak in the latest version of GNOME Shell which upstream GNOME have been working on fixing. While they finalise their plans and merge patches we have decided to press on with including one of the patches which should fix the biggest issues. In our testing it has proven to work well, but we’d like to get wider testing and feedback as soon as possible so we can spot any regressions before release.

It’s worth pointing out that once the patches are merged upstream, we will be issuing another update bringing us back in line with the upstream version.

You can see some of the history of this bug here:

If you’d like to help test, here’s what to do. These instructions are for amd64 based hardware, so you might need to tweak them slightly if you are using, for example, 32bit.

Download the current daily ISO for your hardware from here:
http://cdimage.ubuntu.com/daily-live/current/bionic-desktop-amd64.iso

Install it

Download the patched version of gjs:

wget https://launchpad.net/ubuntu/+source/gjs/1.52.1-1ubuntu1/+build/14773965/+files/gjs_1.52.1-1ubuntu1_amd64.deb https://launchpad.net/ubuntu/+source/gjs/1.52.1-1ubuntu1/+build/14773965/+files/libgjs-dev_1.52.1-1ubuntu1_amd64.deb https://launchpad.net/ubuntu/+source/gjs/1.52.1-1ubuntu1/+build/14773965/+files/libgjs0g_1.52.1-1ubuntu1_amd64.deb

Install them:

sudo dpkg -iO gjs_1.52.1-1ubuntu1_amd64.deb libgjs-dev_1.52.1-1ubuntu1_amd64.deb libgjs0g_1.52.1-1ubuntu1_amd64.deb

Reboot

Just use the desktop, go about your normal business. If you feel that stability and performance are impacted by the new packages, reinstall from the ISO again and don’t install the new packages. See if it’s better on an “out of the box” install.

We’d really love to hear about any stability problems you’re having, so please contribute to the conversation on this hub post and we will closely monitor it and ask for more debugging info if we need it.

Cheers, Will

5 Likes

Those are good news!

Stupid question: will those .deb’s also work on an uptodate beta2 installation? :slight_smile:

1 Like

Good question, yes they will.

2 Likes

Testing it in a VM, is it helpfull?

1 Like

Yeah, that’s good, thanks very much!

That’s great that there are attempts to patch the leak. Unfortunately, it seems that the patches provided in this post are not working on my system. My Ubuntu 18.04 is an upgrade from 17.10.
The memory consumption of the gnome-shell is still visibly increasing every time I do something where the shell action is involved. During last hour the memory gnome-shell memory consumption has increased from 175 MB to 310 MB (for example every alt-tab increases memory footprint 0.2-0.3 MB)

Haven’t seen any poor results with new packages but am wondering why you’re installing libgjs-dev with dpkg? ( most likely result is broken packages
apt would be better for this task or leave the -dev out…

1 Like

Anyway, after one hour of use I do not see any regression or decline in performance. I seem to have tested a large part of the applications installed by default and no beug found at the moment.

But it’s hard to say if the system is more responsive. I have the feeling to have less peak memory consumption increase and surely the rise is more controlled. It remains difficult to evaluate

Yes, you don’t need to install libgjs-dev. Just gjs and libgjs0g

And both gjs and libgjs0g should show up in your regular Ubuntu updates later today so no need to install them manually. Just do your regular updates.

3 Likes

the instructions use “dpkg -iO” that should only install the debs that are already installed on the system and create no issue, are you sure you used the right command? what error are you getting?
it’s basically easier to include the -dev that way than to write “if you have libgjs-dev installed, then grab and install that extra deb otherwise the versions mismatch is going to create issues”

They were supposed to be blocked in proposed during the testing but seems like that request got overlooked :confused: well at this point I guess we can update the instructions then and ask people to simple update

have installed the latest updates and the patches. The memory drain is still there!
Every “alt+tab” increases gnome-shell’s memory usage about 0.1MB to 0.2MB.

1 Like

Could those still having the issue give details on their videocard/driver/session and installed extensions? Details on how you trigger the leak/how you use the shell would also be useful.

Before:
uptime: 3:26, 427.1 MiB

After:
uptime: <1m , 246.8 MiB.
uptime: 4:27, 357.4 MiB
uptime: 5:28, 361.6 MiB

Alt-tabbed like crazy… it went up a bit then… really not sure if that’s significant at all…
uptime: 5:33, 362.9

This doesn’t include the new gnome-shell so the other updated to gnome-shell today, so will update and report back for tomorrow.

I definitely think this has had a positive impact, but then again I am very much not memory constrained.

(Edit : After more time testing, several reboot, the gnome-shell memory seems to be more stable.)

Been testing for about an hour, in Virtual Box. Applied all updates along the way.

Opened Firefox, LibreOffice Writer, Nautilus, grid view, etc. multiple times.

gnome-shell went from something like 275 Mb to 425 Mb, with Firefox open for writing this. (around 1.7 Gb total memory in use.)

Not sure if the patches are doing what they are suppose to. gnome-shell is now at around 445Mb after taking the screenshot.

After the update of the gnome packages this morning on the 18.04 beta version, I have lost the ability to click with the mouse. I can move the pointer but no widget answers to the click event. I can use the keyboard without problem. By the way, the click works on the gdm login screen. Do you think it has something to do with the bug correction discussed here?

Unfortunately that is a different issue. You might want to check these:

Thanks, I have solved the problem by removing the .local and .cache files before restarting a new session. It did not affect other users, only the one I was logged in when updating the packets.

Question : Why is Ubuntu 18.04 shipping with a Gnome System Monitor in version 3.26 as a Snap ? I thought that the idea of Snap was to deliver more up to date Apps.

And the Snap version is slower to launch than the “real” System Monitor in version 3.28.