GNOME Bugzilla – Bug 777537
Gnome 3.22.2 + GDM 3.22.1 : Memory leaks
Last modified: 2021-07-05 14:15:32 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.
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: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1672297
Created attachment 348221 [details] pidstat -r output
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.
Confirmed here too. Arch Linux with gnome-shell 3.22.3-2
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
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
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.
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.
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.
Created attachment 348977 [details] massif log I just tried this.
*** Bug 781809 has been marked as a duplicate of this bug. ***
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: https://drive.google.com/open?id=1c1cSBGLyBW8Rwpkm1x2Gb8Trm0hkzF29 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.
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
Please close this bug. The discussion (with fixes!) continues in: https://gitlab.gnome.org/GNOME/gnome-shell/issues/64
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org 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 https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.