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

Bug #1672297 reported by Paul on 2017-03-13
708
This bug affects 139 people
Affects Status Importance Assigned to Milestone
GNOME Shell
Confirmed
Critical
gjs (Ubuntu)
Critical
Daniel van Vugt
Bionic
Critical
Daniel van Vugt

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.

Daniel van Vugt (vanvugt) wrote :

See also comment #29. It's probably not worth commenting further here till we're on at least version 3.26.3.

shah5xi6 (shah5xi6) wrote :

So does that mean this is a wontfix for 17.10, the current version?

I had to double my RAM to 16GB just to get more than a day out of gnome-shell at work, otherwise as the day goes on, each notification I receive hangs the system for a few seconds and locking and unlocking the screen can take up to a minute by the end of the day. If I happened to be at the bottom of a keystroke at the time it hangs, it acts like the key was held down for the duration - a nightmare in Vim. As others have said, actions like pressing the super key or switching windows seem to consume a few MB each time that it never seems to give back.

Daniel van Vugt (vanvugt) wrote :

If we find a fix that works, then yes it will be backported to 17.10.

florin (florin-arjocu) wrote :

It might be more complicated to fix as there are lots and lots of actions that get to memory leaks. There are some crashes, too. Bad programming, probably, and it might need some fundamental changes in the code and architecture. They are creating lists and objects that are larger and larger on each trigger, without killing any when they are not needed or having a limit to recycle resources. And if they got to this, it might be complicated to find solutions with the same team that created it. I kind of doubt we'll see a solution before the next release.

florin (florin-arjocu) wrote :

PS: and please bring back the Wifi connections list to the menu and add a thick to activate "View inserted password"; see this https://www.youtube.com/watch?v=n2UbE2xh1Q0

Kostadin Stoilov (kmstoilov) wrote :

There is a memory leak generating window previews on gnome shell and since pressing the Super key generates windows previews the memory usage grows exponentially. For me Gnome Shell eats about 100-150 MB every day I leave it running.

I tested this both on an Intel graphics machine and on a VM, in both Artful and Bionic. Both times clean install.

1. on a clean boot open System Monitor and Terminal side by side (or System Monitor and any other window)
2. press Super wait for the window preview and then press ESC (repeat this several times)
3. Observe the memory usage for Gnome Shell System Monitor grow

You can also reproduce this by installing the Alternate Tab extension (https://extensions.gnome.org/extension/15/alternatetab/) which also generates window previews.

1. Alt+Tab between Terminal and System Monitor and watch the Gnome Shell memory usage grow every time.

Another user on reddit also came to a similar conclusion: https://www.reddit.com/r/gnome/comments/7teono/possible_fix_to_improve_gnome_lag/

Effectively gnome shell becomes unusable even on 8 GB of RAM after a week of usage.
I solve the issue by running ALT+F2 and 'r' every morning. People who are not technical of course will not do this and have a horrible experience.

neil king (neil-neilking) wrote :

Its amazing that so many people have this issue and this bug has not yet been fixed. Anyway here's my (reset when idle) workaround (use at your own risk, may have bugs etc.):

https://pastebin.com/8ypFBjQ0

neil king (neil-neilking) wrote :

^ dependency: sudo apt-get install xprintidle

Daniel van Vugt (vanvugt) wrote :

It might have been fixed in a series of changes made in mutter (future version) 3.26.3. It's just unusual and unexpected that Gnome has not done a release for months, so we have not yet tried those fixes. Instead, it looks like we will jump to 3.28 now, soon. So if bionic goes well with 3.28 then we will seriously consider backporting the leak fixes to artful.

This is also one of those bugs that could be subjective. A fix that works for one person might not work for the next. So I guess in order to make sure everyone is on the same page, please ensure you have not installed any Gnome Shell extensions beyond the default Ubuntu ones. Because we don't want to get caught up debugging a gnome-shell extension that most people don't use.

P.S. I stopped working on this bug because I stopped being able to reproduce it.

Kostadin Stoilov (kmstoilov) wrote :

@vanvugt could you try the steps I posted in #46. I can reliably reproduce this on a clean install of Bionic daily in a VM. No extra extensions, just opening window previews with Super multiple times (two windows open).

Thank you.

Changed in gnome-shell:
importance: Unknown → Critical
status: Unknown → Confirmed
Kostadin Stoilov (kmstoilov) wrote :

Here is also a nice video demonstrating the issue: https://www.youtube.com/watch?v=zQCOO-9HZvU

It runs Fedora, but the behaviour is exactly the same on Bionic as well.

PeterPall (peterpall) wrote :

And I was wondering why 2 years ago 0,5 Gigabytes of RAM was plentiful for 32bit and now 4 Gigabytes on 64 bit is too little. Let's hope the window preview problem gets resolved soon.

borovaka (borovaka) wrote :

Actually it is not only "window preview" problem.
It is related to mozjs garbage collector (I think).
You can follow the issue on gnome gitlab: https://gitlab.gnome.org/GNOME/gnome-shell/issues/64

florin (florin-arjocu) wrote :

Sometimes I get the impression that they seem not to be using the newer gnome-shell as their daily driver, as it is quite impossible not to see this happening. :(

PeterPall (peterpall) wrote :

@borovaka: That also matches my experience: If you disable everything that creates previews the gnome-shell's memory usage will grow slower. But if you only have 4 Gigabytes of memory you still have to reboot your computer every 2 hours.

carlix (carlixlinux) wrote :

I posted the bug 3 years ago in 2015 and yesterday the bug expired because nobody saw it, what a irony https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1423773

cement_head (andor-udel) wrote :

Disabling Gnome3 Shell Extensions is not the answer. Solving the underlying bug is the answer. Disabling the G3X will severe cramp usability of G3.

Alex (eneeen) wrote :
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
Daniel van Vugt (vanvugt) wrote :

Thanks for the hints.

I have created a visual profile of the the main overview-related leaks here:
https://gitlab.gnome.org/GNOME/gnome-shell/issues/160

N. W. (nw9165-3201) wrote :

It does not just happen when opening the main overview.

Even when you click on the network/volume/power panel applet and the pop-up opens, the memory usage increases.

Just repeatedly click on the network/volume/power panel applet and watch gnome-shell memory usage grow in system monitor with each click.

Daniel van Vugt (vanvugt) wrote :

Yes I imagine gnome-shell contains multiple different leaks. Each different leak will get a different upstream bug and a different fix.

So this bug may stay open indefinitely as more and more people jump on board. Or we may have to cut it off at some point and use other bug reports for specific cases.

Daniel van Vugt (vanvugt) wrote :

My efforts from last week ran into a dead end because I can't reproduce that massive texture leak any more.

I can however still reproduce the original "smaller" leak (0.5-1.0MB per overview) this bug was about in the first place. And good news: Upstream's experimental fix seems to work:

https://gitlab.gnome.org/GNOME/gjs/merge_requests/114

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)
Ads20000 (ads20000) wrote :

Could the eventual fix be cherry-picked for Ubuntu's GNOME 3.28? Merge requests 114 and 50 (gjs; upstream) are targeted for GNOME 3.30.0 (for example) yet presumably Ubuntu would want the fix in Ubuntu 18.04 rather than shipping with the leak?

Daniel van Vugt (vanvugt) wrote :

Yes, when a fix lands we will push it into 18.04 as a priority.

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)
cement_head (andor-udel) wrote :

In my opinion, Ubuntu 18.04 should not be released until this is fixed - it should be delayed if required. This is O/S killer and will do more to damage the brand name of Ubuntu than releasing a deeply flawed, not-ready-for-prime-time, version. Frankly, Ubuntu 18.04 is unusable as an LTS with this bug present.

Amr Ibrahim (amribrahim1987) wrote :

Upstream has released new versions of accountsservice & polkit to fix some leaks.
https://cgit.freedesktop.org/accountsservice/tag/?h=0.6.46
https://cgit.freedesktop.org/polkit/tag/?h=0.114

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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