gnome-shell uses lots of memory, and grows over time

Bug #1672297 reported by Paul on 2017-03-13
754
This bug affects 150 people
Affects Status Importance Assigned to Milestone
GNOME Shell
Confirmed
Critical
gjs (Ubuntu)
Critical
Unassigned
Bionic
Critical
Unassigned

Bug Description

Upstream:
https://gitlab.gnome.org/GNOME/gnome-shell/issues/64

---

gnome-shell's RSS is growing by 1 MiB every few minutes, and is now at almost 2 GiB.

user 3039 1.8 16.1 4302340 1968476 tty2 Sl+ Mar09 120:17 /usr/bin/gnome-shell

strace output is voluminous; here is a representative sample:

poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
writev(5, [{"\231\n\10\0\n\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0", 32}], 1) = 32
poll([{fd=5, events=POLLIN}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
recvmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"\1\0{\224\0\0\0\0H\0\0\0\0\23\266\32\0\0\0\0\201\242\204\0\0\0\0\0\261.\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(5, 0x7fff60efac90, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(5, 0x7fff60efac90, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
writev(5, [{"\212\5\4\0a\2228\0y\3\5\0%\3\27\4\231\6\5\0\n\0 \0a\2228\0\0\0\0\0"..., 36}, {NULL, 0}, {"", 0}], 3) = 36
poll([{fd=5, events=POLLIN}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
recvmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"\1\0}\224\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(5, 0x7fff60efac90, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
writev(5, [{"\212\n\2\0a\2228\0", 8}, {NULL, 0}, {"", 0}], 3) = 8
recvmsg(5, 0x7fff60efb020, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(12, 0x7fff60efb000, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=16, events=POLLIN}, {fd=26, events=POLLIN}, {fd=29, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, events=POLLIN}, {fd=37, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}], 15, 0) = 0 (Timeout)
recvmsg(5, 0x7fff60efb040, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(5, 0x7fff60efb020, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(12, 0x7fff60efb000, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=16, events=POLLIN}, {fd=26, events=POLLIN}, {fd=29, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, events=POLLIN}, {fd=37, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}], 15, 0) = 0 (Timeout)
recvmsg(5, 0x7fff60efb040, 0) = -1 EAGAIN (Resource temporarily unavailable)
open("/proc/self/stat", O_RDONLY) = 36
fstat(36, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
fcntl(36, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat(36, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(36, "3039 (gnome-shell) R 2930 2917 2"..., 4096) = 354
read(36, "", 3072) = 0
close(36) = 0
recvmsg(5, 0x7fff60efb020, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(12, 0x7fff60efb000, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=16, events=POLLIN}, {fd=26, events=POLLIN}, {fd=29, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, events=POLLIN}, {fd=37, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}], 15, 117885) = 1 ([{fd=4, revents=POLLIN}])
read(4, "\1\0\0\0\0\0\0\0", 16) = 8
recvmsg(5, 0x7fff60efb040, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(5, 0x7fff60efb020, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(12, {msg_name(0)=NULL, msg_iov(1)=[{"[\2\327&h\0@\0i\0@\0(nu\22\n\0I\0\336\2\232\1\265\0038\2\362\2\355\1", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(12, 0x7fff60efb000, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=16, events=POLLIN}, {fd=26, events=POLLIN}, {fd=29, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, events=POLLIN}, {fd=37, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}], 15, 0) = 0 (Timeout)
recvmsg(5, 0x7fff60efb040, 0) = -1 EAGAIN (Resource temporarily unavailable)
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
recvmsg(12, 0x7fff60efaed0, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(5, 0x7fff60efb020, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(12, 0x7fff60efb000, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=16, events=POLLIN}, {fd=26, events=POLLIN}, {fd=29, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, events=POLLIN}, {fd=37, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}], 15, 0) = 1 ([{fd=4, revents=POLLIN}])
read(4, "\1\0\0\0\0\0\0\0", 16) = 8
recvmsg(5, 0x7fff60efb040, 0) = -1 EAGAIN (Resource temporarily unavailable)
open("/proc/self/stat", O_RDONLY) = 36
fstat(36, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
fcntl(36, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat(36, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(36, "3039 (gnome-shell) R 2930 2917 2"..., 4096) = 354
read(36, "", 3072) = 0
close(36) = 0
recvmsg(5, 0x7fff60efb020, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(12, 0x7fff60efb000, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=16, events=POLLIN}, {fd=26, events=POLLIN}, {fd=29, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, events=POLLIN}, {fd=37, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}], 15, 1) = 0 (Timeout)
recvmsg(5, 0x7fff60efb040, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=12, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=12, revents=POLLOUT}])
writev(12, [{"\217\3\4\0i\0@\0\0\0\0\0\0\0\0\0+\0\1\0", 20}, {NULL, 0}, {"", 0}], 3) = 20
poll([{fd=12, events=POLLIN}], 1, -1) = 1 ([{fd=12, revents=POLLIN}])
recvmsg(12, {msg_name(0)=NULL, msg_iov(1)=[{"\1\2\331&\0\0\0\0\250\0`\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(12, 0x7fff60efaf60, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(12, 0x7fff60efaf60, 0) = -1 EAGAIN (Resource temporarily unavailable)
ioctl(6, DRM_IOCTL_I915_GEM_MADVISE, 0x7fff60efa960) = 0
ioctl(6, DRM_IOCTL_I915_GEM_BUSY, 0x7fff60efa910) = 0
ioctl(6, DRM_IOCTL_I915_GEM_MADVISE, 0x7fff60efa900) = 0
ioctl(6, DRM_IOCTL_I915_GEM_PWRITE, 0x7fff60efa9b0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_BUSY, 0x7fff60efac50) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fff60efaba0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7fff60efad30) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SW_FINISH, 0x7fff60efae30) = 0
ioctl(6, _IOC(_IOC_READ|_IOC_WRITE, 0x64, 0x69, 0x40), 0x7fff60efadb0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fff60efae30) = 0
ioctl(6, DRM_IOCTL_I915_GEM_MADVISE, 0x7fff60efadb0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_BUSY, 0x7fff60efad80) = 0
ioctl(6, DRM_IOCTL_I915_GEM_MADVISE, 0x7fff60efad70) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fff60efad90) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fff60efae90) = 0

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: gnome-shell 3.23.91-0ubuntu4
ProcVersionSignature: Ubuntu 4.10.0-11.13-generic 4.10.1
Uname: Linux 4.10.0-11-generic x86_64
ApportVersion: 2.20.4-0ubuntu2
Architecture: amd64
Date: Mon Mar 13 19:17:51 2017
DisplayManager: gdm3
InstallationDate: Installed on 2016-12-02 (100 days ago)
InstallationMedia: Ubuntu-GNOME 16.10 "Yakkety Yak" - Release amd64 (20161012.1)
ProcEnviron:
 LANGUAGE=en_AU:en
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

Paul (i41bktob-launchpad-net) wrote :
Jeremy Bicha (jbicha) wrote :

Can you reproduce this now? There have been several 3.23.92 updates this week (in particular gjs) that might have helped with this bug.

Changed in gnome-shell (Ubuntu):
status: New → Incomplete
Paul (i41bktob-launchpad-net) wrote :

Yes, I upgraded to 3.23.92-0ubuntu1 yesterday and it's at 459 MiB after about 15 hours' runtime and growing at a similar rate.

user 2307 1.5 3.8 2717744 469980 tty2 Sl+ Mar16 21:34 /usr/bin/gnome-shell

Any next steps for debugging this?

Jeremy Bicha (jbicha) wrote :

Thank you for taking the time to report this bug. Could you report this issue to GNOME?

https://wiki.ubuntu.com/Bugs/Upstream/GNOME

I don't know how to debug memory leak issues. If you know how to use IRC, you can ask on #gnome-shell on irc.gnome.org .

Changed in gnome-shell (Ubuntu):
status: Incomplete → Confirmed
Paul (i41bktob-launchpad-net) wrote :

Thanks for the suggestion; my symptoms are an exact match for this existing bug, including memory leaked each time a different window gets focus (especially with Alt+Tab):

https://bugzilla.gnome.org/show_bug.cgi?id=777537

Cliff Carson (ccarson1) wrote :

Saw what appeared to be a memory leak in gnome-shell so set up a pidstat trace to see the memory activity. Added this trace text the monitored thought the day. The increase in memory usage appears to be consistent and not related to what activity being done on the system. Most of the morning and early afternoon the system was unused.

Jeremy Bicha (jbicha) wrote :

Cliff, thank you. Could you please forward that to GNOME instead?

Changed in gnome-shell (Ubuntu):
importance: Undecided → Medium
Videonauth (videonauth) wrote :

As of now this still persists in Ubuntu 17.10 with the gnome-shell for 3.26, 8 hours of uptime and the shell is at nearly 1 GB size.

Changed in gnome-shell (Ubuntu):
status: Confirmed → Triaged
Changed in gnome-shell (Ubuntu):
importance: Medium → High
summary: - gnome-shell leaks RAM, almost 2 GiB RSS after 4 days
+ gnome-shell uses lots of memory, and grows over time
Daniel van Vugt (vanvugt) wrote :

Confirmed. Seems I can make gnome-shell grow by about 1MB per second if I move the mouse over the dock continuously, or scrub across the panel menus continuously. That might not be the only problem but the rate of growth is quite significant.

Paul (i41bktob-launchpad-net) wrote :

Tried to get a Massif profile, starting a new gnome-shell with --replace, but it fails before it can replace the running process due to bug #1700465:

$ valgrind --tool=massif --num-callers=32 --log-file=/tmp/gnome-shell.valgrind.log gnome-shell --replace

(gnome-shell:30065): mutter-WARNING **: Can't initialize KMS backend: Could not get session ID: No such file or directory

If we can't replace it, it should be possible to get the display manager to launch gnome-shell in valgrind at login. The order of execution seems to be: gdm3 -> gdm-session-worker -> gdm-wayland-session -> gnome-session-binary -> gnome-shell. I hit a dead end when trying to find config files though.

Daniel van Vugt (vanvugt) wrote :

It's often easier to replace the binary itself with a debug script. For example:

  mv /usr/bin/gnome-shell /usr/bin/gnome-shell.bin

Now create a new 'gnome-shell' file that's a script which launches gnome-shell.bin under a profiler/debugger, like:

  #!/bin/sh
  exec MYPROFILER $0.bin $*

and remember to:

  chmod 755 /usr/bin/gnome-shell

Paul (i41bktob-launchpad-net) wrote :

Ah yep, that would do it. Just be sure to have the script check the username, because even if you're on a single-user system the gdm user also runs a gnome-shell:

#!/bin/sh
if [ $USER = your_username_here ] ; then exec valgrind --tool=massif --num-callers=32 --log-file=/tmp/gnome-shell.valgrind.log.%p $0.bin $* ; fi
exec $0.bin $*

I ran this and experimented with all the usual applications. Valgrind's RSS was growing slowly as you'd expect until I played a video, then it exploded to > 6 GiB and Wayland hung. I killed Valgrind with -HUP and it did produce a valid profile (attached). Please check if this is what you are after.

I'm now running it again but won't test video playback this time.

Paul (i41bktob-launchpad-net) wrote :

I see the same leak you do when interacting with the panel. In fact, just pressing the Meta key twice to bring up and hide the overview leaks 1 MiB of RAM each time. Even switching workspaces leaks memory. These are all things that jank once gnome-session's footprint has grown to unreasonable sizes, so presumably that jank is a symptom of bloated datastructures taking more cycles to negotiate.

Attached is another profile, from a session that didn't end with Wayland pooping its pants.

Daniel van Vugt (vanvugt) wrote :

Thanks Paul.

For readability you might want to just run 'ms_print massif.out.3205' and attach the output of that in future.

Daniel van Vugt (vanvugt) wrote :

Next, please try to find and install debug symbol packages for those libraries near the top of the output listed with "???":

96.92% (48,673,660B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->44.20% (22,195,990B) 0x3A2632E4: ??? (in /usr/lib/x86_64-linux-gnu/libjpeg.so.8.1.2)
| ->44.04% (22,118,517B) 0x3A26342D: ??? (in /usr/lib/x86_64-linux-gnu/libjpeg.so.8.1.2)
| | ->44.04% (22,118,517B) 0x3A263786: ??? (in /usr/lib/x86_64-linux-gnu/libjpeg.so.8.1.2)
| | ->44.04% (22,118,517B) 0x3A255C6B: jinit_master_decompress (in /usr/lib/x86_64-linux-gnu/libjpeg.so.8.1.2)
| | ->44.04% (22,118,517B) 0x3A24AA7B: jpeg_start_decompress (in /usr/lib/x86_64-linux-gnu/libjpeg.so.8.1.2)
| | ->44.04% (22,118,517B) 0x3A003747: ??? (in /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so)
| | ->44.04% (22,118,517B) 0x8714A82: gdk_pixbuf_loader_write (in /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3611.0)
| | ->44.04% (22,118,517B) 0x87111A9: ??? (in /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3611.0)
| | ->44.04% (22,118,517B) 0x871223A: gdk_pixbuf_new_from_stream (in /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3611.0)
| | ->44.04% (22,118,517B) 0x73B7FF7: ??? (in /usr/lib/x86_64-linux-gnu/libmutter-1.so.0.0.0)
| | ->44.04% (22,118,517B) 0x530BD54: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.5400.1)
| | ->44.04% (22,118,517B) 0x58E200E: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
| | ->44.04% (22,118,517B) 0x58E1643: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
| | ->44.04% (22,118,517B) 0x769A7FA: start_thread (pthread_create.c:465)
| | ->44.04% (22,118,517B) 0x79C6B0D: clone (clone.S:95)

Then re-run 'ms_print', assuming a new profile doesn't need to be created.

Daniel van Vugt (vanvugt) wrote :

Actually it's not the "top" of the output that's interesting. The snapshot #1 just shows where memory went initially on start-up (to loading images). That doesn't represent the ongoing growth problem though. You need to scroll down to later snapshots in the ms_print output to see where the growth is coming from, like snapshot 51:

 47 68,075,238,605 72,060,280 63,908,218 8,152,062 0
 48 70,175,452,080 73,101,400 64,835,851 8,265,549 0
 49 71,750,692,416 74,288,744 65,927,330 8,361,414 0
 50 72,800,335,769 75,355,616 66,877,167 8,478,449 0
 51 73,849,979,162 81,425,416 72,853,026 8,572,390 0
89.47% (72,853,026B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->19.72% (16,059,766B) 0x58BF577: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
| ->17.59% (14,320,777B) 0x58D70F4: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
| | ->13.29% (10,825,417B) 0x58D7587: g_slice_alloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5400.1)
| | | ->05.48% (4,459,320B) 0x564F7E4: g_type_create_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5400.1)
| | | | ->04.96% (4,040,752B) 0x5630096: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5400.1)
| | | | | ->04.84% (3,937,672B) 0x6C05829: ??? (in /usr/lib/x86_64-linux-gnu/mutter/libmutter-clutter-1.so)
| | | | | | ->04.55% (3,708,152B) 0x5630CF5: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5400.1)
| | | | | | | ->02.97% (2,417,720B) 0x5631FBC: g_object_newv (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5400.1)
| | | | | | | | ->02.97% (2,417,720B) 0x6911B0C: ??? (in /usr/lib/libgjs.so.0.0.0)
| | | | | | | | ->02.97% (2,417,720B) 0xE0BBD5B: ??? (in /usr/lib/x86_64-linux-gnu/libmozjs-52.so.0.0.0)
| | | | | | | | ->02.97% (2,417,720B) 0xE0BBF87: ??? (in /usr/lib/x86_64-linux-gnu/libmozjs-52.so.0.0.0)
| | | | | | | | ->02.97% (2,417,720B) 0xDF51842: JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) (in /usr/lib/x86_64-linux-gnu/libmozjs-52.so.0.0.0)
| | | | | | | | ->02.97% (2,417,720B) 0x692B2A4: gjs_call_function_value (in /usr/lib/libgjs.so.0.0.0)
| | | | | | | | ->02.97% (2,417,720B) 0x6910454: ??? (in /usr/lib/libgjs.so.0.0.0)

So you then need debug symbols for libraries like:
  /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5400.1
  /usr/lib/x86_64-linux-gnu/mutter/libmutter-clutter-1.so
  /usr/lib/libgjs.so.0.0.0
  /usr/lib/x86_64-linux-gnu/libmozjs-52.so.0.0.0

Which sounds like it's getting closer to the core of the problem.

Paul (i41bktob-launchpad-net) wrote :

I've installed most of the debug symbol packages, and the attached Massif profile has far fewer unknowns. However, this isn't a proper run, because when I try to log in now, gnome-shell grinds for a minute or so and then quits. Works fine without Valgrind, of course. I suspect it has some form of watchdog timer and is killing itself.

==1764== Process terminating with default action of signal 1 (SIGHUP)
==1764== at 0x76A1072: pthread_cond_wait@@GLIBC_2.3.2 (futex-internal.h:88)
==1764== by 0xDCAB863: js::ConditionVariable::wait(js::LockGuard<js::Mutex>&) (ConditionVariable.cpp:118)
==1764== by 0xDCABAB4: js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) (ConditionVariable.cpp:134)
==1764== by 0xE0A1D14: js::HelperThread::threadLoop() (HelperThreads.cpp:786)
==1764== by 0xE0C2351: js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::Start(void*) (Thread.h:234)
==1764== by 0x769A7FB: start_thread (pthread_create.c:465)
==1764== by 0x79C6B0E: clone (clone.S:95)

Daniel van Vugt (vanvugt) wrote :

Thanks Paul. The only slightly conclusive information I got from that so far is:

https://bugzilla.gnome.org/show_bug.cgi?id=789955

So let's see how that one goes first. Looks like that's a secondary issue though and not the biggest repeating issue.

Daniel van Vugt (vanvugt) wrote :

P.S. To start gnome-shell manually, this seems to do the trick:

 1. Log into a virtual terminal.
 2. gnome-shell --display-server --wayland --mode=ubuntu

So you can modify that command as required.

Changed in gnome-shell (Ubuntu):
assignee: nobody → Daniel van Vugt (vanvugt)
status: Triaged → In Progress
Daniel van Vugt (vanvugt) wrote :

Looks like upstream has had the same idea this week:
https://git.gnome.org/browse/mutter/log/?h=gnome-3-26&qt=grep&q=leak

Those fixes are coming in 3.26.3 (so I guess Ubuntu 18.04 soon).

Jeremy Bicha (jbicha) on 2017-11-09
Changed in mutter (Ubuntu):
importance: Undecided → High
status: New → Triaged
Changed in mutter:
importance: Unknown → Medium
status: Unknown → Fix Released
Changed in gnome-shell (Ubuntu):
assignee: Daniel van Vugt (vanvugt) → nobody
status: In Progress → Triaged
Cristiano Gavião (cvgaviao) wrote :

I'm also having huge memory usage for gnome-shell. I noted that after have watched a movie using another display (my smart-tv) the memory used by it are on 3.4Gb !!!

ApportVersion: 2.20.7-0ubuntu3.6
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
DisplayManager: gdm3
DistroRelease: Ubuntu 17.10
InstallationDate: Installed on 2017-11-02 (36 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
Package: mutter
PackageArchitecture: amd64
ProcEnviron:
 LANG=en_US.UTF-8
 TERM=xterm-256color
 SHELL=/bin/bash
 XDG_RUNTIME_DIR=<set>
 PATH=(custom, no user)
ProcVersionSignature: Ubuntu 4.13.0-19.22-generic 4.13.13
Tags: artful
Uname: Linux 4.13.0-19-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip libvirt lpadmin plugdev sambashare sudo
_MarkForUpload: True

tags: added: apport-collected artful

apport information

apport information

apport information

apport information

Ryan C (chappersrh) wrote :

At any given time: immediately after reboot, immediately after restarting gnome-shell (alt+F2 --> "r"), and during regular use gnome-shell is consuming at least 4GB RAM. I'm happy to provide a memory profile but I don't know how to do that so I need help.

# ps auxwww | grep gnome-shell
gdm 1595 0.0 1.2 3696204 211144 tty1 Sl+ Dec08 0:23 /usr/bin/gnome-shell
<my user> 2176 0.4 2.6 4063428 431096 tty2 Sl+ Dec08 3:01 /usr/bin/gnome-shell

# ps -p 1595,2176 -Fl
F S USER PID PPID C PRI NI P SZ WCHAN RSS PSR STIME TTY TIME CMD
0 S gdm 1595 1559 0 80 0 * 924307 poll_s 211648 0 Dec08 tty1 00:00:24 /usr/bin/gnome-shell
0 S <my user> 2176 2060 0 80 0 * 1017742 poll_s 433852 1 Dec08 tty2 00:03:36 /usr/bin/gnome-shell

jesus225 (jesus225) wrote :

No matter what you do, gnome-shell eats up RAM slowly. In case you shutdown your machine after every use, you will not notice it, however, if you keep it running or tend to suspend/hibernate, it will reach a point when it will swap.

After one day of usage (just web browsing) gnome-shell increased ram usage from 100M to 350M. It does not free it up even if you close all windows. In my 4GB machine, it means that either I restart every day or I start facing swap issues the second day.

Daniel van Vugt (vanvugt) wrote :

Also note we're still waiting for mutter and gnome-shell v3.26.3 to reach Ubuntu 18.04. Some leak fixes have gone into 3.26.3 but it's not yet released. It will be interesting to see what, if any, improvement v3.26.3 makes for people here.

Maraschin (carlo-maraschin) wrote :

Hi, I'm running ubuntu 17.10 with gnome 3.26.2

I noticed today that every time I press the "windows" key it consumes about 5 MB extra and just keeps growing ...

Maraschin (carlo-maraschin) wrote :

more info: my current setup has 4 monitors running with 2560x1440

Norbert (nrbrtx) wrote :

Also seen on AskUbuntu - https://askubuntu.com/q/1001069/66509 .

Chelmite (steve-kelem) wrote :

Regarding #32, The total shown is 16,293,840 and used is 1,781,036, which is about 11% of the total, not more than total. (With that many digits, commas help.)

Chelmite (steve-kelem) wrote :

I'm trying to track down something that makes system performance degrade in less than an hour. Whenever I switch desktops, move my cursor to a place where a tooltip is displayed, open a pull-down menu, the display freezes for 5-15 seconds before, for example, the menu or tooltip is released.

If I kill -1 my gnome-shell, performance is restored...for a while.

I decided to take some measurements.
% ps guax | grep gnome-shell
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 15805 6.3 0.6 4037064 401804 tty2 Rl+ 10:10 1:07 /usr/bin/gnome-shell

The VSZ and RSS grow slowly, if at all, if I don't switch desktops, bring up menus, etc. Here are snapshots at 15 second intervals:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 15805 8.5 1.3 4755216 862708 tty2 Sl+ 10:10 10:41 /usr/bin/gnome-shell
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 15805 8.5 1.3 4755216 862912 tty2 Sl+ 10:10 10:42 /usr/bin/gnome-shell
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 15805 8.5 1.3 4755216 862912 tty2 Sl+ 10:10 10:43 /usr/bin/gnome-shell
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 15805 8.5 1.3 4755216 863128 tty2 Sl+ 10:10 10:44 /usr/bin/gnome-shell
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 15805 8.5 1.3 4755216 863344 tty2 Sl+ 10:10 10:45 /usr/bin/gnome-shell

After 2 hours, the ps reports go from
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 15805 6.3 0.6 4037064 401804 tty2 Rl+ 10:10 1:07 /usr/bin/gnome-shell

to
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 15805 8.7 1.2 4725708 821640 tty2 Rl+ 10:10 11:27 /usr/bin/gnome-shell

VSZ increases by 688.6K, or 17%.
RSS increases by 419.8K, or 104%

I'm running GNOME Shell 3.26.2 on Ubuntu 17.10 x86-64.

Chelmite (steve-kelem) wrote :

If I press the Ubuntu key over and over, showing the overview of all the desktops, and then again to return to the normal view of the current desktop, RSS for gnome-desktop increases rapidly (measurements taken at 15-second intervals.

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 15805 9.0 1.2 4776896 820820 tty2 Sl+ 10:10 12:27 /usr/bin/gnome-shell
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 15805 9.0 1.2 4790452 831004 tty2 Rl+ 10:10 12:31 /usr/bin/gnome-shell
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 15805 9.1 1.2 4799632 849868 tty2 Sl+ 10:10 12:36 /usr/bin/gnome-shell
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 15805 9.1 1.3 4807764 859832 tty2 Sl+ 10:10 12:42 /usr/bin/gnome-shell
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 15805 9.2 1.3 4812364 865236 tty2 Sl+ 10:10 12:46 /usr/bin/gnome-shell

After kill -1 15805, I get:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
skelem 27800 14.5 0.5 4072104 362428 tty2 Sl+ 12:31 0:06 /usr/bin/gnome-shell

Daniel van Vugt (vanvugt) wrote :

It's important to remember that RSS increases is no indication of a leak - it will rise and fall according to how busy the machine is and not how much new memory the process has allocated. Please ignore all RSS values as they are going to be unpredictable and misleading.

As for VSZ, that's kind of related to potential leaks. The problem with VSZ is that it's a measure of the address space mappings size and is also not a measure of regular memory allocated by the process. Although you can use changes in VSZ to detect leaks and bloat, address space used by VSZ is not an indication of the memory requirements of the process.

Probably a better field to monitor for actual leaks is VmData which you can find in:
  /proc/PID/status

VmData is a more realistic indication of memory allocated by the process.

Chelmite (steve-kelem) wrote :

VmData: 636560 kB 10:30
VmData: 848276 kB 15:45

That's up 33% in 5.25 hours, during which I wasn't interacting with the computer, so there shouldn't have been any demands on gnome.

naisanza (naisanza) wrote :

The entire UI lags far behind as well. When gnome-shell using around 500 MB RAM, middle clicking Nautilus freezes the entire system UI for up to 10 seconds. No mouse, no keyboard, no clicking.

florin (florin-arjocu) wrote :

Yes, I got some freezes, too, even longer than 10 seconds. One time I restarted the laptop as I did not know what is going on, another time at some point Gnome crashed and started by itself. This did not happen in Unity.

Jaroslav Svoboda (multi-flexi) wrote :

Just noticed it in updated Bionic. After boot uses around 450MB of VRAM and then suddenly jumps to 1200MB and more when only Chrome is running. When Chrome is closed it does not change. Using Geforce 960 GTX with 390 drivers. Freezes and also black streak flashes on one of monitors sometimes. When the process is killed it restarts and drops back to less then 500MB.

Changed in gnome-shell:
importance: Unknown → Critical
status: Unknown → Confirmed
Changed in gnome-shell (Ubuntu):
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in mutter (Ubuntu):
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in gnome-shell (Ubuntu):
status: Triaged → In Progress
Changed in mutter (Ubuntu):
status: Triaged → In Progress
tags: added: rls-bb-incoming
affects: mutter → ubuntu
no longer affects: ubuntu
tags: removed: rls-bb-incoming
Changed in gjs (Ubuntu Bionic):
status: New → Confirmed
importance: Undecided → High
Changed in gnome-shell (Ubuntu Bionic):
assignee: Daniel van Vugt (vanvugt) → nobody
Changed in mutter (Ubuntu Bionic):
assignee: Daniel van Vugt (vanvugt) → nobody
description: updated
Changed in gnome-shell (Ubuntu Bionic):
status: In Progress → Invalid
Changed in mutter (Ubuntu Bionic):
status: In Progress → Invalid
Changed in gnome-shell (Ubuntu Bionic):
status: Invalid → Confirmed
Changed in gjs (Ubuntu Bionic):
status: Confirmed → Triaged
no longer affects: mutter (Ubuntu)
no longer affects: mutter (Ubuntu Bionic)
Will Cooke (willcooke) on 2018-04-12
Changed in gnome-shell (Ubuntu Bionic):
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in gjs (Ubuntu Bionic):
assignee: nobody → Daniel van Vugt (vanvugt)
26 comments hidden view all 106 comments
Daniel van Vugt (vanvugt) wrote :

@cement_head: The desktop team agrees. We'll be releasing *something* for this bug this week. Only 3 days to final freeze...

@Amr: Those are probably better left as separate bugs to this one.

Changed in gjs (Ubuntu Bionic):
status: Triaged → In Progress
importance: High → Critical
no longer affects: gnome-shell (Ubuntu Bionic)
no longer affects: gnome-shell (Ubuntu)
Daniel van Vugt (vanvugt) wrote :

Here's a patch to fix the biggest of the leaks.

I notice however that upstream is working on additional fixes. But those fixes are very new and experimental. What I am providing here is the more significant and mature of the leak fixes currently being proposed.

Rocko (rockorequin) wrote :

Is that patch getting into Ubuntu soon? I tried applying it to the latest gjs source package and installing the patched package, but it left gdm in an un-startable state, even when I uninstalled it and reinstalled the default gjs package.

Daniel van Vugt (vanvugt) wrote :

Sounds like you might have made a mistake. Just wait till the patch is released properly.

Rocko (rockorequin) wrote :

Well, quite. I built and installed it with "./configure --prefix=/usr && make && sudo make install" and it's obviously more complicated than that. Is there a guide somewhere for how to build and install gnome-shell and its components in ubuntu?

Daniel van Vugt (vanvugt) wrote :

Yes, many Ubuntu packages are customized and often don't work unless you use the same customization options in your build. You can find out what those are by running 'apt-get source FOO' and then looking in debian/rules. However it's too complicated to write a clear guide for.

Also, it sounds like you may be building the wrong project. The leak is in project 'gjs', not 'gnome-shell'.

Changed in gjs (Ubuntu Bionic):
status: In Progress → Fix Committed
cement_head (andor-udel) wrote :

Glad to see that this bug is about to be squished...

Rocko (rockorequin) wrote :

I managed to build and install a patched gjs last night thanks to a helpful hint from a fellow user (ie to use debuild -us -uc -b to build it instead of make and make install).

Initially, gnome-shell was using around 170 MB according to gnome-system-monitor (atop says consistently says it is using around 100 MB more). It stayed that way until the next morning when something made it jump to 250 MB, and an hour or so later it jumped to 350 MB (it's hard to tell if it jumped all at once or slowly increased, because I think there's a bug in gnome-system-monitor that makes it stop auto-refreshing until you click on its window - when I clicked on gnome-system-monitor, gnome-shell's displayed usage jumped 100 MB each time).

Usage stayed at around 350 MB for the morning and most of the afternoon. Eventually, I restarted gnome-shell with ALT-F2 and 'r' and usage dropped immediately to 120 MB. It stayed there for about half an hour until it suddenly jumped to 170 MB, and it has been sitting on that for the last two hours.

gnome-shell with an _unpatched_ gjs on my system will go to 450 MB or more in less than an hour, so I think there's a definite improvement with the patch, but there are still some big leaks there.

Daniel van Vugt (vanvugt) wrote :

Yes, we know that is only one of the leak fixes. The other fixes (upstream, not reviewed yet) are less mature and have not been included in the Ubuntu patch.

Daniel van Vugt (vanvugt) wrote :

Seems not committed anywhere yet.

Changed in gjs (Ubuntu Bionic):
status: Fix Committed → In Progress
Daniel van Vugt (vanvugt) wrote :

Rocko,

the other thing to consider is that the patch in comment #68 stops all types of GObject leaks, including those holding resources outside of normal memory. So if for example that texture leak returns (which I expect it may), that will consume texture memory even faster than you see main memory being used. It's mostly an invisible resource, contributing to the VSIZE only, but still using very real and very limited physical/GPU memory. Hidden resource leaks like that would explain slow-downs probably better than the visible memory growth would.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gjs - 1.52.1-1ubuntu1

---------------
gjs (1.52.1-1ubuntu1) bionic; urgency=medium

  * Add fix-crashes-lp1763878-revert-575f1e2e077.patch to fix shutdown
    crashes (LP: #1763878)
  * Add some patches to solve large memory leaks (LP: #1672297)
    - fix-leaks-lp1672297-1-context-Add-API-to-force-GC-schedule.patch
    - fix-leaks-lp1672297-2-object-Queue-a-forced-GC-when-toggling-down.patch
    - Note: More such patches are under review so this list may grow in future.

 -- Daniel van Vugt <email address hidden> Mon, 16 Apr 2018 14:30:31 +0800

Changed in gjs (Ubuntu Bionic):
status: In Progress → Fix Released
Daniel van Vugt (vanvugt) wrote :

I wonder if we should keep using this bug as the additional leak fixes land in future?

Leaks are likely to come and go indefinitely over time as the code changes, so we should try to decide the acceptance criteria for closing this bug. And when it would be more appropriate to open new similar bugs.

carlix (carlixlinux) wrote :

If you really want to close this bug PLEASE WATCH THIS https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1423773

greenmandd (sunget) wrote :

Guys, i am not programmer, but i`m wander why gnome have so many memory leaks? Most of them have been known for years and nobody cares till Ubuntu LTS 18.04 release. Bad code, bad programming, or other reason?!

Sergei (markovs-i-mail) wrote :

Yep, that's about ignorant gnome-shell team and really outdated toolkit. Ubuntu should use KDE.

carlix (carlixlinux) wrote :

And you should... SEE THIS LINK
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1423773 which is the most important memory leak and I posted it 3 years ago, could be possible that just ONE developer take this seriously?

Daniel van Vugt (vanvugt) wrote :

Let's keep this open till we have the full set up upstream fixes in Ubuntu:
https://gitlab.gnome.org/GNOME/gnome-shell/issues/64

Changed in gjs (Ubuntu Bionic):
status: Fix Released → In Progress
Jeremy Bicha (jbicha) wrote :

I am unsubscribing ubuntu-sponsors since I don't see anything here now that is ready for sponsoring. Please feel free to resubscribe when you have something else that needs sponsoring.

Gianluca Masci (g-masci) wrote :

Any news on this?

Daniel van Vugt (vanvugt) wrote :
Download full text (9.4 KiB)

After some minutes I logged in (Ubuntu 18.04, gnome-shell) something used a lot of memory (approx. 1GB). I checked gnome-system-monitor, but there was not any process which used more memory as usual (neither user nor system). Nothing was opened or launched. Only one thing helped: logout and login again.
I have no idea what was that, and I can not repeat it again.
(gnome shell is extremely laggy :-( )

On máj 3 2018, at 9:08 de, Daniel van Vugt <email address hidden> wrote:
>
> Looks like we're still waiting for upstream to land:
> https://gitlab.gnome.org/GNOME/gjs/merge_requests/122
>
> from the list:
> https://gitlab.gnome.org/GNOME/gnome-shell/issues/64
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1672297
>
> Title:
> gnome-shell uses lots of memory, and grows over time
>
> Status in GNOME Shell:
> Confirmed
> Status in gjs package in Ubuntu:
> In Progress
> Status in gjs source package in Bionic:
> In Progress
>
> Bug description:
> Upstream:
> https://gitlab.gnome.org/GNOME/gnome-shell/issues/64
>
> ---
> gnome-shell's RSS is growing by 1 MiB every few minutes, and is now at
> almost 2 GiB.
>
> user 3039 1.8 16.1 4302340 1968476 tty2 Sl+ Mar09 120:17
> /usr/bin/gnome-shell
>
> strace output is voluminous; here is a representative sample:
> poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
> writev(5, [{"\231\n\10\0\n\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0", 32}], 1) = 32
> poll([{fd=5, events=POLLIN}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
> recvmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"\1\0{\224\0\0\0\0H\0\0\0\0\23\266\32\0\0\0\0\201\242\204\0\0\0\0\0\261.\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
> recvmsg(5, 0x7fff60efac90, 0) = -1 EAGAIN (Resource temporarily unavailable)
> recvmsg(5, 0x7fff60efac90, 0) = -1 EAGAIN (Resource temporarily unavailable)
> poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
> writev(5, [{"\212\5\4\0a\2228\0y\3\5\0%\3\27\4\231\6\5\0\n\0 \0a\2228\0\0\0\0\0"..., 36}, {NULL, 0}, {"", 0}], 3) = 36
> poll([{fd=5, events=POLLIN}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
> recvmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"\1\0}\224\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
> recvmsg(5, 0x7fff60efac90, 0) = -1 EAGAIN (Resource temporarily unavailable)
> poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
> writev(5, [{"\212\n\2\0a\2228\0", 8}, {NULL, 0}, {"", 0}], 3) = 8
> recvmsg(5, 0x7fff60efb020, 0) = -1 EAGAIN (Resource temporarily unavailable)
> recvmsg(12, 0x7fff60efb000, 0) = -1 EAGAIN (Resource temporarily unavailable)
> poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=16, events=POLLIN}, {fd=26, events=POLLIN}, {fd=29, events=POLLIN}, {fd=32, events=POLLIN}, {fd=34, events=POLLIN}, {fd=37, events=POLLIN}, {fd=38, events=POLLIN}, {fd=40, events=POLLIN}, {fd=42, events=POLLIN}, {fd=43, events=POLLIN}], 15, 0) = 0 (Timeout)
> recvmsg(5, 0x7fff60efb040, 0) = -1 EAGAIN (Resource temporarily...

Read more...

Ads20000 (ads20000) wrote :

https://gitlab.gnome.org/GNOME/gjs/merge_requests/122 is now merged, all the other merge requests linked to in https://gitlab.gnome.org/GNOME/gnome-shell/issues/64 are now merged. Daniel could we have soon have a -proposed package of backports of these fixes up for testing? :)

Daniel van Vugt (vanvugt) wrote :

It's on the (backlog) queue: https://trello.com/b/3VYBPFaR/ubuntu-desktop-1810-cycle

Although this doesn't need to wait for me. Anyone could cherry pick and propose the remaining fixes.

Daniel van Vugt (vanvugt) wrote :

It appears the only gjs fixes we are missing are:
  https://gitlab.gnome.org/GNOME/gjs/merge_requests/121
  https://gitlab.gnome.org/GNOME/gjs/merge_requests/122

However the first is more to do with performance, and a little to do with memory usage. It's also included in upstream gjs releases 1.52.3 and later. The second is included in release 1.53.2. So we'll just do a version upgrade of gjs in cosmic for that right now and people can try it out.

As for the rest of the fixes:
  https://gitlab.gnome.org/GNOME/gnome-shell/issues/64
they are in mutter. Either already released in mutter version 3.28.1, or too small to backport early, or actually not to do with memory usage.

So in summary I think we are only missing gjs!121 and gjs!122 in Ubuntu:
 * cosmic: will get it as part of an update to the latest gjs version.
 * bionic: may get it later if people feel it's useful.

Please correct me if I am wrong and have missed anything.

Daniel van Vugt (vanvugt) wrote :

I think the cleanest first step will be -> bug 1778660

That will allow us to drop the patches we're carrying and also get in sync with Debian.

Iain Lane (laney) wrote :

This bug was fixed in the package gjs - 1.53.3-1

---------------
gjs (1.53.3-1) experimental; urgency=medium

  [ Simon McVittie ]
  * d/watch: Watch for development releases
  * New upstream development release

  [ Iain Lane ]
  * New upstream development releases 1.53.2 and 1.53.3

 -- Iain Lane <email address hidden> Wed, 27 Jun 2018 18:20:12 +0100

gjs (1.52.3-2) unstable; urgency=medium

  * Team upload
  * d/p/context-Add-API-to-force-GC-schedule.patch,
    d/p/object-Queue-a-forced-GC-when-toggling-down.patch,
    d/p/context-Ensure-force_gc-flag-is-not-lost-if-the-idle-is-s.patch:
    Add patches from upstream version 1.53.1 to make GC more aggressive
    (LP: #1672297)

 -- Simon McVittie <email address hidden> Thu, 17 May 2018 11:13:54 +0100

gjs (1.52.3-1) unstable; urgency=medium

  * New upstream release

 -- Tim Lunn <email address hidden> Tue, 08 May 2018 17:18:07 +1000

gjs (1.52.2-1) unstable; urgency=medium

  * New upstream release

 -- Tim Lunn <email address hidden> Fri, 20 Apr 2018 17:18:55 +1000

Changed in gjs (Ubuntu):
status: In Progress → Fix Released
Changed in gjs (Ubuntu):
assignee: Daniel van Vugt (vanvugt) → Ubuntu Desktop (ubuntu-desktop)
Changed in gjs (Ubuntu Bionic):
assignee: Daniel van Vugt (vanvugt) → Ubuntu Desktop (ubuntu-desktop)
Daniel van Vugt (vanvugt) wrote :

Technically, being in cosmic-proposed only makes it Fix Committed. Not yet Fix Released.

Changed in gjs (Ubuntu):
status: Fix Released → Fix Committed
Iain Lane (laney) wrote :

On Wed, Jul 04, 2018 at 09:30:05AM -0000, Daniel van Vugt wrote:
> Technically, being in cosmic-proposed only makes it Fix Committed. Not
> yet Fix Released.

Daniel, I know this, but syncpackage marks bugs as Fix Released and it's
manual work to go back and change it because nothing will do that for
you as the package migrates. I am, as I always do, tracking my upload
through proposed into the release.

If you want to do this manual work yourself, you can feel free of
course, but I personally don't think it's the best use of time.

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gjs - 1.53.3-1

---------------
gjs (1.53.3-1) experimental; urgency=medium

  [ Simon McVittie ]
  * d/watch: Watch for development releases
  * New upstream development release

  [ Iain Lane ]
  * New upstream development releases 1.53.2 and 1.53.3

 -- Iain Lane <email address hidden> Wed, 27 Jun 2018 18:20:12 +0100

Changed in gjs (Ubuntu):
status: Fix Committed → Fix Released
Iain Lane (laney) wrote :

OK, in this instance Simon had quoted this bug reference in the changelog for a previous version:

  https://tracker.debian.org/news/958430/accepted-gjs-1523-2-source-into-unstable/

lucky :-)

Changed in gjs (Ubuntu):
assignee: Ubuntu Desktop (ubuntu-desktop) → nobody
Changed in gjs (Ubuntu Bionic):
assignee: Ubuntu Desktop (ubuntu-desktop) → nobody
Daniel van Vugt (vanvugt) wrote :

Laney,

Thanks for doing the work. I know that you know...

My main concern is about effective communication with the 141 users subscribed here. And that means using a correct status value which I am happy to do manually.

Nick Timkovich (nicktimko) wrote :

For us end-users, does "Fix Released" just mean released to a nightly/unstable/private package repo? Because https://packages.ubuntu.com/bionic/gjs still lists the version at 1.52.1, that means this still unreleased in stable?

What's the status to look out for when an `apt-get upgrade` will fix the issue?

Doug McMahon (mc3man) wrote :

@ Nick Timkovich
The 'fix released' for 18.04 (1.52.1-1ubuntu1) is to the extent as seen in comment 78 which may not be as developed as the 'fix released' for 18.10 , i.e comment 96
The bionic task for gjs as shown at top still says 'In progress' which *may* mean there are further gjs patches under consideration for 18.04..

Reuben Helms (reuben.helms) wrote :

I recently changed my Ubuntu 18.04 installation to use i3 window manager due to this issue, but alas, it's not enough, as GNOME is used for my login screen. After 3 days away from my desk, the memory is 38.2G/39.2G and swap is 14.6/22.4G and the /usr/bin/gnome-shell process owned by gdm has taken 78.7% of my memory with 45.1G VIRT and 30.8G RES in htop.

Having to wait until 3 to 4 months for an upstream bugfix and doing daily reboots is more disruption that I'm willing to put up with for a "stable" release (and a LTS at that).

Any tips for installing a desktop manager for the login screen that isn't gnome, or disabling gnome shell (and replacing with something not gnome) until this gets fixed in a manner that is accessible to consumers of the current stable release.

waffen (mlacunza) wrote :

Well for this bug I need to install Xubuntu and lightdm, run very fast with no issues, BUT looks like Firefox is eating a lot of RAM in both desktops, for my job I need FF to be opened all the time, so the time to time I need to close it and relaunch it, if not FF freezing my desktop, now even Chrome eats a lower portion of RAM than FF... are you have similar problems with FF + ubuntu?

Balazs Pere (perebal-sze) wrote :
Download full text (10.2 KiB)

Ubuntu 18.04.1 is coming soon (tomorrow?). What about the bug fixes?

I know a temporary method, but it is not so nice (but it works, saves
~400MB RAM): run after login
sudo killall -u gdm
killall gnome-software

One more, clear gnome-calendar. It launches automatically, uses
constantly 2-400MB RAM, and do nothing.

sudo apt remove gnome-calendar

waffen <email address hidden> ezt írta (időpont: 2018. júl. 16., H, 5:01):
>
> Well for this bug I need to install Xubuntu and lightdm, run very fast
> with no issues, BUT looks like Firefox is eating a lot of RAM in both
> desktops, for my job I need FF to be opened all the time, so the time to
> time I need to close it and relaunch it, if not FF freezing my desktop,
> now even Chrome eats a lower portion of RAM than FF... are you have
> similar problems with FF + ubuntu?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1672297
>
> Title:
> gnome-shell uses lots of memory, and grows over time
>
> Status in GNOME Shell:
> Confirmed
> Status in gjs package in Ubuntu:
> Fix Released
> Status in gjs source package in Bionic:
> In Progress
>
> Bug description:
> Upstream:
> https://gitlab.gnome.org/GNOME/gnome-shell/issues/64
>
> ---
>
> gnome-shell's RSS is growing by 1 MiB every few minutes, and is now at
> almost 2 GiB.
>
> user 3039 1.8 16.1 4302340 1968476 tty2 Sl+ Mar09 120:17
> /usr/bin/gnome-shell
>
> strace output is voluminous; here is a representative sample:
>
> poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
> writev(5, [{"\231\n\10\0\n\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0", 32}], 1) = 32
> poll([{fd=5, events=POLLIN}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
> recvmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"\1\0{\224\0\0\0\0H\0\0\0\0\23\266\32\0\0\0\0\201\242\204\0\0\0\0\0\261.\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
> recvmsg(5, 0x7fff60efac90, 0) = -1 EAGAIN (Resource temporarily unavailable)
> recvmsg(5, 0x7fff60efac90, 0) = -1 EAGAIN (Resource temporarily unavailable)
> poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
> writev(5, [{"\212\5\4\0a\2228\0y\3\5\0%\3\27\4\231\6\5\0\n\0 \0a\2228\0\0\0\0\0"..., 36}, {NULL, 0}, {"", 0}], 3) = 36
> poll([{fd=5, events=POLLIN}], 1, -1) = 1 ([{fd=5, revents=POLLIN}])
> recvmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"\1\0}\224\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
> recvmsg(5, 0x7fff60efac90, 0) = -1 EAGAIN (Resource temporarily unavailable)
> poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
> writev(5, [{"\212\n\2\0a\2228\0", 8}, {NULL, 0}, {"", 0}], 3) = 8
> recvmsg(5, 0x7fff60efb020, 0) = -1 EAGAIN (Resource temporarily unavailable)
> recvmsg(12, 0x7fff60efb000, 0) = -1 EAGAIN (Resource temporarily unavailable)
> poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=16, events=POLLIN}, {fd=26, events=POLL...

MyUbunty (a-uyuntuone-r) wrote :

Can we PLEASE get some kind of coherent update on this for bionic. Most distros (debian unstable, arch) already incorporated this fix. Is this fix coming? Is any part of it coming? This is issues is serious enough that it needs addressing, please respond!

cement_head (andor-udel) wrote :

Will all these memory bleed issues be patched in the upcoming 18.04.1 LTS release?

florin (florin-arjocu) wrote :

Yesterday I discovered another Gnome software bug, (another) one of Files (Nautilus). Without any reason, Files was running 4+% of the CPU for a long time, without even touching it. Might be some interaction, if I see that again, will file a separate bug report.

Displaying first 40 and last 40 comments. View all 106 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

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