GNOME Shell

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

Bug #1672297 reported by Paul
878
This bug affects 178 people
Affects Status Importance Assigned to Milestone
GNOME Shell
Confirmed
Critical
gjs (Ubuntu)
Fix Released
Critical
Hassan Kibiti
Bionic
Fix Released
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)

See original description
Revision history for this message
Paul (i41bktob-launchpad-net) wrote :
Revision history for this message
Jeremy Bícha (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
Revision history for this message
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?

Revision history for this message
Jeremy Bícha (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
Revision history for this message
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

Revision history for this message
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.

Revision history for this message
Jeremy Bícha (jbicha) wrote :

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

Robert Ancell (robert-ancell)
Changed in gnome-shell (Ubuntu):
importance: Undecided → Medium
Revision history for this message
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.

Sebastien Bacher (seb128)
Changed in gnome-shell (Ubuntu):
status: Confirmed → Triaged
Daniel van Vugt (vanvugt)
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
Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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)

Revision history for this message
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.

Revision history for this message
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.

Daniel van Vugt (vanvugt)
Changed in gnome-shell (Ubuntu):
assignee: nobody → Daniel van Vugt (vanvugt)
status: Triaged → In Progress
Revision history for this message
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 Bícha (jbicha)
Changed in mutter (Ubuntu):
importance: Undecided → High
status: New → Triaged
Bug Watch Updater (bug-watch-updater)
Changed in mutter:
importance: Unknown → Medium
status: Unknown → Fix Released
Daniel van Vugt (vanvugt)
Changed in gnome-shell (Ubuntu):
assignee: Daniel van Vugt (vanvugt) → nobody
status: In Progress → Triaged
Revision history for this message
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 !!!

Revision history for this message
Ryan C (chappersrh) wrote : apport information

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
Revision history for this message
Ryan C (chappersrh) wrote : Dependencies.txt

apport information

Revision history for this message
Ryan C (chappersrh) wrote : GsettingsChanges.txt

apport information

Revision history for this message
Ryan C (chappersrh) wrote : JournalErrors.txt

apport information

Revision history for this message
Ryan C (chappersrh) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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 ...

Revision history for this message
Maraschin (carlo-maraschin) wrote :

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

Revision history for this message
Norbert (nrbrtx) wrote :

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

Revision history for this message
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.)

Revision history for this message
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.

Revision history for this message
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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Bug Watch Updater (bug-watch-updater)
Changed in gnome-shell:
importance: Unknown → Critical
status: Unknown → Confirmed
Daniel van Vugt (vanvugt)
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
Sebastien Bacher (seb128)
tags: removed: rls-bb-incoming
Daniel van Vugt (vanvugt)
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
Daniel van Vugt (vanvugt)
Changed in gjs (Ubuntu Bionic):
status: Confirmed → Triaged
Daniel van Vugt (vanvugt)
no longer affects: mutter (Ubuntu)
no longer affects: mutter (Ubuntu Bionic)
Will Cooke (willcooke)
Changed in gnome-shell (Ubuntu Bionic):
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in gjs (Ubuntu Bionic):
assignee: nobody → Daniel van Vugt (vanvugt)
Daniel van Vugt (vanvugt)
Changed in gjs (Ubuntu Bionic):
status: Triaged → In Progress
importance: High → Critical
Daniel van Vugt (vanvugt)
no longer affects: gnome-shell (Ubuntu Bionic)
no longer affects: gnome-shell (Ubuntu)
Sebastien Bacher (seb128)
Changed in gjs (Ubuntu Bionic):
status: In Progress → Fix Committed
Daniel van Vugt (vanvugt)
Changed in gjs (Ubuntu Bionic):
status: Fix Committed → In Progress
Launchpad Janitor (janitor)
Changed in gjs (Ubuntu Bionic):
status: In Progress → Fix Released
40 comments hidden view all 120 comments
Revision history for this message
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?!

Revision history for this message
Sergei (markovs-i-mail) wrote :

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

Revision history for this message
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?

Revision history for this message
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
Revision history for this message
Jeremy Bícha (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.

Revision history for this message
Gianluca Masci (g-masci) wrote :

Any news on this?

Revision history for this message
Daniel van Vugt (vanvugt) 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

Revision history for this message
Balazs Pere (perebal-sze) wrote : Re: [Bug 1672297] Re: gnome-shell uses lots of memory, and grows over time
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...

Revision history for this message
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? :)

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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
Daniel van Vugt (vanvugt)
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)
Revision history for this message
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
Revision history for this message
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> ]

Revision history for this message
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
Revision history for this message
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 :-)

Sebastien Bacher (seb128)
Changed in gjs (Ubuntu):
assignee: Ubuntu Desktop (ubuntu-desktop) → nobody
Changed in gjs (Ubuntu Bionic):
assignee: Ubuntu Desktop (ubuntu-desktop) → nobody
Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
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..

Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
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...

Revision history for this message
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!

Revision history for this message
cement_head (andorjkiss) wrote :

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

Revision history for this message
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.

Revision history for this message
chris pollock (cpollock) wrote :

This is:
 apt-cache policy gnome-shell
gnome-shell:
  Installed: 3.28.2-0ubuntu0.18.04.1
  Candidate: 3.28.2-0ubuntu0.18.04.1

apt-cache policy evolution
evolution:
  Installed: 3.28.1-2
  Candidate: 3.28.1-2

lsb_release -crid
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic

uname -a
Linux localhost 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Aug 20 08:46:13 localhost evolution.desktop[2662]: Memory pressure relief: Total: res = 19537920/16986112/-2551808, res+swap = 14004224/11452416/-2551808
Aug 20 08:46:19 localhost evolution.desktop[2662]: Memory pressure relief: Total: res = 16916480/16908288/-8192, res+swap = 11382784/11374592/-8192
Aug 20 08:46:58 localhost evolution.desktop[2662]: Memory pressure relief: Total: res = 16908288/16908288/0, res+swap = 11374592/11374592/0
Aug 20 08:47:29 localhost evolution.desktop[2662]: Memory pressure relief: Total: res = 16908288/16912384/4096, res+swap = 11378688/11378688/0
Aug 20 08:47:59 localhost evolution.desktop[2662]: Memory pressure relief: Total: res = 16912384/16912384/0, res+swap = 11378688/11378688/0

Not sure if this pertains to this bug at all. I noticed the above every few minutes in my syslog after upgrading to 18.04.1 last week.

Revision history for this message
Balazs Pere (perebal-sze) wrote :
  • Screenshot Edit (100.8 KiB, image/png; name="=?UTF-8?B?S8OpcGVybnnFkWvDqXAgZXJyxZFsOiAyMDE4LTA5LTAyIDIzLTQ2LTQ0LnBuZw==?=")
Download full text (11.2 KiB)

I installed Ubuntu 18.10 gjs and libgjs0g 1.53.3-1 (of Ubuntu 18.10) to
Ubuntu 18.04. It seems that the memory leak lives forever...
Memory usage started from 170MB, and after two hours is over 360MB.
[image: Képernyőkép erről: 2018-09-02 23-46-44.png]

chris pollock <email address hidden> ezt írta (időpont: 2018. aug.
20., H, 16:51):

> This is:
> apt-cache policy gnome-shell
> gnome-shell:
> Installed: 3.28.2-0ubuntu0.18.04.1
> Candidate: 3.28.2-0ubuntu0.18.04.1
>
> apt-cache policy evolution
> evolution:
> Installed: 3.28.1-2
> Candidate: 3.28.1-2
>
> lsb_release -crid
> Distributor ID: Ubuntu
> Description: Ubuntu 18.04.1 LTS
> Release: 18.04
> Codename: bionic
>
> uname -a
> Linux localhost 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC
> 2018 x86_64 x86_64 x86_64 GNU/Linux
>
> Aug 20 08:46:13 localhost evolution.desktop[2662]: Memory pressure relief:
> Total: res = 19537920/16986112/-2551808, res+swap =
> 14004224/11452416/-2551808
> Aug 20 08:46:19 localhost evolution.desktop[2662]: Memory pressure relief:
> Total: res = 16916480/16908288/-8192, res+swap = 11382784/11374592/-8192
> Aug 20 08:46:58 localhost evolution.desktop[2662]: Memory pressure relief:
> Total: res = 16908288/16908288/0, res+swap = 11374592/11374592/0
> Aug 20 08:47:29 localhost evolution.desktop[2662]: Memory pressure relief:
> Total: res = 16908288/16912384/4096, res+swap = 11378688/11378688/0
> Aug 20 08:47:59 localhost evolution.desktop[2662]: Memory pressure relief:
> Total: res = 16912384/16912384/0, res+swap = 11378688/11378688/0
>
> Not sure if this pertains to this bug at all. I noticed the above every
> few minutes in my syslog after upgrading to 18.04.1 last week.
>
> --
> 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\...

Revision history for this message
kerozoli (kerozoli) wrote :

Gnome 3.30 is out. Are there any ETA or plan to fix this Critical issue?

Revision history for this message
Balazs Pere (perebal-sze) wrote :

No comment...

Daniel van Vugt (vanvugt)
Changed in gjs (Ubuntu Bionic):
status: In Progress → Triaged
Revision history for this message
Balazs Pere (perebal-sze) wrote :

I switched from nvidia driver to nouveau driver and the huge memory usage disappeared. Small jumps (increase) in memory usage stayed with us.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

This bug is fixed in Ubuntu 18.10, but beware 18.10 also brings a new separate leak: bug 1800165.

This bug is not yet fixed in Ubuntu 18.04 because the fix for this one also causes a performance regression in 18.10 that we don't want to repeat in 18.04:

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

We will need to backport that fix as part of the fix here so the performance regression is never seen in 18.04. However, technically we are required to get the performance fix into 18.10 before we can proceed with 18.04 here. :S

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I don't know what I was thinking... This bug is clearly declared fixed in 18.04 already:

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

If anyone experiences new leaks in 18.10 then please see bug 1800165. For anything else, please open a new bug.

Changed in gjs (Ubuntu Bionic):
status: Triaged → Fix Released
Hassan Kibiti (kibitih)
Changed in gjs (Ubuntu):
assignee: nobody → Hassan Kibiti (kibitih)
Norbert (nrbrtx)
tags: removed: artful zesty
Revision history for this message
Josh Myer (josh-joshisanerd) wrote :

FWIW, I have a pretty consistent reproduction of this on my 20.04 machine here. Restarting gnome-shell with Alt-F2 then "r" causes all the window management stuff to go away, but doesn't actually kill the process that's reporting the giant resident set size. Manually killing that pid also causes the WM chrome to disappear for a second and then pop back once a new gnome-shell process spawns. That one comes up almost instantly with a huge (but smaller, at least) RSS:

0] jbm@complexity:~/Downloads $ ps l 650626
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 1000 650626 2554 20 0 6884676 2449912 - Rsl ? 62:14 /usr/bin/gnome-shell
0] jbm@complexity:~/Downloads $ kill 650626

(run top to get the new PID)

130] jbm@complexity:~/Downloads $ ps l 665168
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 1000 665168 2554 20 0 6248912 1988284 poll_s Ssl ? 0:57 /usr/bin/gnome-shell

So, it's gone from 2449912 to 1988284. That isn't nothing: 2.3GiB vs 1.9GiB, but it's still a heck of a lot of RAM for a newly-spawned process.

Hope this report helps!

Revision history for this message
Tomasz Owczarek (t0m4z) wrote :

Still happening on Ubuntu 18.04.6: gnome-shell 3.28.4:

KiB Mem : 20210320 total, 5287136 free, 9839436 used, 5083748 buff/cache
KiB Swap: 38653948 total, 35113980 free, 3539968 used. 9823860 avail Mem

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 3664 tomek 20 0 8356864 3.843g 81904 S 81.7 19.9 378:32.26 gnome-shell

Revision history for this message
Sami Farin (safarigo) wrote :

I have 32 GiB RAM.

Oct 03 16:21:10 kernel: Out of memory: Killed process 448186 (gnome-shell) total-vm:17570844kB, anon-rss:336828kB, file-rss:2548kB, shmem-rss:7665392kB, UID:500 pgtables:28128kB oom_score_adj:200

Running with gnome-shell 43.0 and gjs-1.74.0:

21d62400000-7ffe2b9a2000 ---p 00000000 00:00 0 [rollup]
Rss: 4645900 kB
Pss: 4625270 kB
Pss_Anon: 347040 kB
Pss_File: 9415 kB
Pss_Shmem: 4268815 kB
Shared_Clean: 12584 kB
Shared_Dirty: 20184 kB
Private_Clean: 7368 kB
Private_Dirty: 4605764 kB
Referenced: 4002232 kB
Anonymous: 347040 kB
LazyFree: 0 kB
AnonHugePages: 133120 kB
ShmemPmdMapped: 0 kB
FilePmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB

Revision history for this message
Sami Farin (safarigo) wrote :

Regarding continually increasing Pss_Shmem, diffing numa_maps has these...
Can these glfw mappings be reason for the increased memory usage?

59d20d348000 default file=/usr/bin/gnome-shell anon=1 dirty=1 active=0 N0=1 kernelpagesize_kB=4
 59d20d988000 default heap anon=26945 dirty=26945 active=0 N0=26945 kernelpagesize_kB=4
-775066988000 default file=/memfd:glfw-shared\040(deleted) dirty=234 mapmax=2 active=0 N0=234 kernelpagesize_kB=4
+775064ebb000 default file=/memfd:glfw-shared\040(deleted) dirty=231 mapmax=2 active=0 N0=231 kernelpagesize_kB=4
+775065042000 default file=/memfd:glfw-shared\040(deleted) dirty=240 active=0 N0=240 kernelpagesize_kB=4
+7750651c9000 default file=/dev/dri/card0
+7750655c9000 default file=/memfd:glfw-shared\040(deleted) dirty=233 active=0 N0=233 kernelpagesize_kB=4
+775065750000 default file=/memfd:glfw-shared\040(deleted) dirty=242 active=0 N0=242 kernelpagesize_kB=4
+7750658d7000 default file=/memfd:glfw-shared\040(deleted) dirty=235 active=0 N0=235 kernelpagesize_kB=4
+775065a5e000 default file=/memfd:glfw-shared\040(deleted) dirty=228 active=0 N0=228 kernelpagesize_kB=4
+775065be5000 default file=/dev/dri/card0
+775065fe5000 default file=/memfd:glfw-shared\040(deleted) dirty=237 mapmax=2 active=0 N0=237 kernelpagesize_kB=4
+77506616c000 default file=/memfd:glfw-shared\040(deleted) dirty=246 active=0 N0=246 kernelpagesize_kB=4
+7750662f3000 default file=/memfd:glfw-shared\040(deleted) dirty=240 active=0 N0=240 kernelpagesize_kB=4
+77506647a000 default file=/memfd:glfw-shared\040(deleted) dirty=232 active=0 N0=232 kernelpagesize_kB=4
+77506667a000 default file=/memfd:glfw-shared\040(deleted) dirty=232 active=0 N0=232 kernelpagesize_kB=4
+775066801000 default file=/memfd:glfw-shared\040(deleted) dirty=241 active=0 N0=241 kernelpagesize_kB=4
+775066988000 default file=/memfd:glfw-shared\040(deleted) dirty=234 active=0 N0=234 kernelpagesize_kB=4
 775066b0f000 default file=/memfd:glfw-shared\040(deleted) dirty=227 active=0 N0=227 kernelpagesize_kB=4
-775066c96000 default file=/dev/dri/card0
+775066d88000 default file=/memfd:glfw-shared\040(deleted) dirty=234 active=0 N0=234 kernelpagesize_kB=4
+775066f0f000 default file=/memfd:glfw-shared\040(deleted) dirty=227 active=0 N0=227 kernelpagesize_kB=4
 775067096000 default file=/memfd:glfw-shared\040(deleted) dirty=236 active=0 N0=236 kernelpagesize_kB=4
 77506721d000 default file=/memfd:glfw-shared\040(deleted) dirty=245 active=0 N0=245 kernelpagesize_kB=4

Revision history for this message
Sami Farin (safarigo) wrote :

3952 KiB extra memory usage by gnome-shell when I change window of kitty (terminal).
Two megabytes for one press of alt-tab! 🫣

Revision history for this message
Jonathan Stucklen (stuckj) wrote (last edit ):

Thanks @vanvugt, this was helpful. I'm running ubuntu 23.10. It's been about a week since I rebooted and I noticed swap usage was quite high. I've got 32GB of RAM and am a developer with a bunch of stuff open at once. Decided to investigate. Closed everything, but left just gnome running and a terminal. Did a swapoff -a to clear swap and dropped caches to get it as close to just what was allocated as possible. It still showed 14GB of memory used with 5GB in cache. That seems high.

So, ran this to take a look at VmData for gnome-shell:

  cat /proc/$(pgrep -f /usr/bin/gnome-shell)/status | grep VmData

That reveals:

  VmData: 1231000 kB

That seems a bit excessive.

Full disclosure. I do use extensions. It's too bare-bones without them.

I miss being able to Alt-F2 -> R and reboot gnome, but it appears to not be possible now with Wayland.

> 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.

Revision history for this message
Jonathan Stucklen (stuckj) wrote :

Turns out after a fresh reboot the memory usage isn't much different after I close all apps and VmData for gnome shell is only about 400MB. So, perhaps this isn't the smoking gun I thought it was.

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

Other bug subscribers

Related questions

Remote bug watches

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