After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 777537 - Gnome 3.22.2 + GDM 3.22.1 : Memory leaks
Gnome 3.22.2 + GDM 3.22.1 : Memory leaks
Product: gnome-shell
Classification: Core
Component: general
Other Linux
: Normal critical
: ---
Assigned To: gnome-shell-maint
: 781809 (view as bug list)
Depends on:
Reported: 2017-01-20 14:06 UTC by Alex
Modified: 2021-07-05 14:15 UTC
See Also:
GNOME target: ---
GNOME version: ---

pidstat -r output (10.71 KB, text/plain)
2017-03-18 11:02 UTC, Cliff Carson
Valgrind log (86.24 KB, application/x-xz)
2017-03-30 00:07 UTC, Paul
full Valgrind log (884.22 KB, application/x-xz)
2017-03-30 03:42 UTC, Paul
Valgrind log, gnome-shell killed with Meta.exit(0) (1.02 MB, application/x-xz)
2017-03-30 06:10 UTC, Paul
massif log (12.89 KB, application/x-xz)
2017-03-30 08:50 UTC, Hussam Al-Tayeb

Description Alex 2017-01-20 14:06:54 UTC
When using GDM, gnome-shell at start uses about 80 MB of RAM, but after ~5 hours of consistent using it consumes ~300MB of RAM. Restarting the gnome-shell puts it back to 80 MB.
When using other display managers, this problem does not occur.
The memory seems to be taken mostly when I switch windows with alt+tab.
Comment 1 Paul 2017-03-17 00:35:53 UTC
Confirmed in 3.23.92-0ubuntu1. Switching between windows by clicking on them leaks about 300 KiB each time; Alt+Tab leaks about double that.

Relevant Launchpad bug:
Comment 2 Cliff Carson 2017-03-18 11:02:51 UTC
Created attachment 348221 [details]
pidstat -r output
Comment 3 Cliff Carson 2017-03-18 11:03:35 UTC
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.
Comment 4 Márcio 2017-03-18 19:32:53 UTC
Confirmed here too.
Arch Linux with gnome-shell 3.22.3-2
Comment 5 Paul 2017-03-30 00:07:45 UTC
Created attachment 348964 [details]
Valgrind log

Confirmed in 3.24.0-0ubuntu1.

I've attached a preliminary Valgrind log. Most of the required debug symbols are included. I've now installed the remaining debug packages and will run this again.

The log doesn't seem to account for enough leaked memory (tens of megabytes, while it should be hundreds), so there may be some active pointers; I'll use --show-leak-kinds=all next time.

valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --log-file=valgrind_gnome-shell_preliminary.txt gnome-shell --replace
Comment 6 Paul 2017-03-30 03:42:50 UTC
Created attachment 348967 [details]
full Valgrind log

Attached is a complete Valgrind log which should include reachable memory as well as unreachable. At this point, after a 3½ hour run, Valgrind was using over 2 GiB of RAM, so I estimate this represents about 300 to 400 MiB leaked. Unfortunately, Valgrind only reports about 10 MiB lost and 30 MiB reachable, which is an order of magnitude too low.

valgrind --tool=memcheck --leak-check=full --leak-resolution=high --show-leak-kinds=all --num-callers=20 --log-file=valgrind_gnome-shell.txt gnome-shell --replace
Comment 7 Jonas Ådahl 2017-03-30 04:52:12 UTC
How is the leak check done? Or more specifically, how is it finalized? If you run "restart" or "debugexit", mutter/gnome-shell will do various cleanup things, which might end up cleaning up the things that were "leaked". To avoid this clean up step, you can try the following:

 1) Open looking glass (Alt-F2 -> type "lg")
 2) Enter "Meta.exit(0)"

This will cause gnome-shell to simply run exit(0) immediately.

Note that doing this will leave you with no window manager, so you'll have to know how to recover from that.
Comment 8 Paul 2017-03-30 06:10:06 UTC
Created attachment 348971 [details]
Valgrind log, gnome-shell killed with Meta.exit(0)

Good idea. I was just starting another gnome-shell --replace, so yes it was being shut down gracefully.

Attached is a Valgrind log from a run terminated by Meta.exit(0) as you instructed. I killed it when Valgrind was using 1.2 GiB of RAM, so I guess about 150 MiB of gnome-shell memory had been leaked at that point. This Valgrind report shows a bit more lost memory but still doesn't seem like the right order of magnitude to me.
Comment 9 Jonas Ådahl 2017-03-30 07:44:21 UTC
Another thing you can try is massif (part of valgrind) to record the heap usage and allocations. Haven't tried this with gnome-shell, it might be unbearably slow, but anyhow.. running

  valgrind --tool=massif --pages-as-heap=yes gnome-shell

will produce a recording of the heap usage called massif.out.[pid]. You can use "ms_print massif.out.[pid]" to generate a gigantic text file with a graph and a lot of call stacks for allocations. With that we could possibly see what stack keeps eating more and more.
Comment 10 Hussam Al-Tayeb 2017-03-30 08:50:01 UTC
Created attachment 348977 [details]
massif log

I just tried this.
Comment 11 i2000s 2017-04-27 06:15:50 UTC
*** Bug 781809 has been marked as a duplicate of this bug. ***
Comment 12 87craft 2018-02-26 21:28:24 UTC
I'm noticing a similar problem. I'm using GNOME 3.26.2 on Wayland. I made a core dump when it was at 4.2 GB or so, and it's using almost 6.6 GB after switching workspaces a few times.

Link to the heap dump:

Using the hot corner made memory use jump, and changing workspaces from that view had an even stronger effect. Changing workspaces using Ctrl+Alt+Up/Down also causes this, but not as quickly.

I turned off all extensions, and it didn't seem to have much effect on the memory leak.
Comment 13 nospam_mrzap000 2018-03-04 21:31:23 UTC
Same here. Gnome 3.26.2 on xorg, ubuntu 17.10.

I that helps the with debugging, memory usage increases by about 40Mb each time the desktop  wallpaper is changed (@ full HD resolution). 

gnome-shell reached 3.1Gb usage in half a day after installing variety, that keeps on changing wallpapers every 5 minutes

10404 mrzap     20   0 6858556 3,119g  80124 S   2,7 40,4  27:19.28 gnome-shell
Comment 14 Daniel van Vugt 2018-04-16 05:39:10 UTC
Please close this bug.

The discussion (with fixes!) continues in:
Comment 15 GNOME Infrastructure Team 2021-07-05 14:15:32 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
and create a new ticket at

Thank you for your understanding and your help.