GNOME Bugzilla – Bug 654269
significant memory leak in gnome-shell 3.0.2
Last modified: 2011-10-08 21:00:57 UTC
Created attachment 191533 [details] graph of memory leak over time Bug: On my system, gnome-shell clearly "leaks" memory at a rate of ~2 MB/min... if I use either the open-source nouveau drivers or the closed nvidia package (either 275.x series or beta 280.x series). Reproduce this bug: Log into gnome and monitor gnome-shell memory consumption. Supporting data: I ran the following script upon logging in to Gnome, running from another tty (ALT+CTRL+F1) then came back to my graphical X running on tty8 and just let the mouse sit there idle. I stopped collecting data after 45 min as you can see in the graphic (attached). #!/bin/bash for i in {1..6000}; do number=$(ps -A --sort -rss -o comm,rss | head -n 3 | grep gnome-shell | awk '{ print $2 }') correct=$(echo "scale=2;$number/1024" | bc) echo "$correct $i" >> /dev/shm/mem_usage.txt sleep 60s done Actual results: memory leaks at the rate of about 2 MB/min when gnome-shell is simply idle. I think this is related to https://bugzilla.gnome.org/show_bug.cgi?id=642652 Build Date & Platform: gnome-shell 3.0.2 on Arch Linux
Can you get a valgrind log?
Created attachment 191587 [details] my first time using valgrind. Let me know if you need it run with other switches.
(In reply to comment #2) > Created an attachment (id=191587) [details] > per request of dev I found another usage of valgrind (https://wiki.ubuntu.com/Valgrind) and ran it again using the following: $ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=valgrind.log /usr/bin/gnome-shell
Created attachment 191594 [details] 2nd try at providing info
Created attachment 191595 [details] 2nd try-valgrind log replaces prev upload incorrectly identified as 'plain/text'
Created attachment 191596 [details] [review] main: Fix small memory leak in main.c ==17386== 1,669 (88 direct, 1,581 indirect) bytes in 1 blocks are definitely lost in loss record 4,090 of 4,151 ==17386== at 0x4C24AF4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==17386== by 0x691B099: g_malloc0 (in /usr/lib/libglib-2.0.so.0.2800.8) ==17386== by 0x692006A: g_option_context_new (in /usr/lib/libglib-2.0.so.0.2800.8) ==17386== by 0x5124C57: meta_get_option_context (in /usr/lib/libmutter.so.0.0.0) ==17386== by 0x401D4F: main (in /usr/bin/gnome-shell)
All the other "definite" leaks are in libGL. Is there a better way to see what's being lost there?
Wish I knew... glad to provide info upon request, but this is over my head.
Installing some debug infos for most everything there would be a big help;
@Jasper - gonna need some pretty specific steps from you.
Based on your comment, I built the Arch Linux package for glib2-git (http://aur.archlinux.org/packages.php?ID=40977). These exhibit a very similar behavior to the "stable" ones in the office Arch [core] repo. Log attached.
Created attachment 191603 [details] valgrind log using glib2-git per comment 11
In your log, at the top, there's a lot of lines that look like: --19868-- Reading syms from /usr/lib/gnome-shell/libgnome-shell.so (0x4e2c000) --19868-- object doesn't have a symbol table --19868-- Reading syms from /usr/lib/libmutter.so.0.0.0 (0x50d1000) --19868-- object doesn't have a symbol table You're going to have to fix as many of those as possible.
(In reply to comment #13) > In your log, at the top, there's a lot of lines that look like: > > --19868-- Reading syms from /usr/lib/gnome-shell/libgnome-shell.so (0x4e2c000) > --19868-- object doesn't have a symbol table > --19868-- Reading syms from /usr/lib/libmutter.so.0.0.0 (0x50d1000) > --19868-- object doesn't have a symbol table > > You're going to have to fix as many of those as possible. Can you explain how I would got about it? I'm not a programmer; I know enough bash commands to be dangerous :)
I have no idea how to do it on Arch. I looked around and found that Arch doesn't have split debug info (WTF?), so you're gonna have to recompile. Look at https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces but stop after "Getting the trace" step and instead use valgrind once you have all the packages. This will take a while to rebuild. To make sure you've got all the packages, just run a simple `gdb gnome-shell` and look for any lines that look like: Reading symbols from ...(no debugging symbols found) However, to be honest, I would instead recommend using F15, on LiveCD/LiveUSB if possible. Here we have split debuginfo packages, so getting some debuginfo would be as easy as: $ gdb gnome-shell ... Reading symbols from /usr/bin/gnome-shell...(no debugging symbols found)...done. Missing separate debuginfos, use: debuginfo-install gnome-shell-3.0.2-4.fc15.x86_64 However, I recognize that you may not be willing to take the jump.
(In reply to comment #15) > However, to be honest, I would instead recommend using F15, on LiveCD/LiveUSB > if possible. Here we have split debuginfo packages, so getting some debuginfo > would be as easy as: > > $ gdb gnome-shell > ... > Reading symbols from /usr/bin/gnome-shell...(no debugging symbols > found)...done. > Missing separate debuginfos, use: debuginfo-install > gnome-shell-3.0.2-4.fc15.x86_64 > > However, I recognize that you may not be willing to take the jump. I'm glad to try. I actually just put Ubuntu on a spare partition and booted into it. I was a bit pissed to see that 11.04 doesn't use gnome-shell. I'm d/l'ing fedora-15-x86_64-Live-desktop.iso now and will try as you suggest. Just out curiosity, on your system, does gnome-shell leak as it does on mine? If you use my script and let your desktop just idle for say, 45 min. Can you get a dataset showing memory usage increasing at a linear rate? If not, perhaps this is a problem with Arch packages, and not with "gnome-shell" itself?
Created attachment 191613 [details] valgrind log under F15
OK... install F15 to a spare partition, updated, and enabled nvidia drivers per the forum post. I'm now in gnome using nvidia drivers v275.09.07. I see the same behavior of leaking under F15 by the way. $ sudo debuginfo-install gnome-shell-3.0.2-4.fc15.x86_64 <<installed>> $ gdb gnome-shell GNU gdb (GDB) Fedora (7.2.90.20110703-40.fc15) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/gnome-shell...Reading symbols from /usr/lib/debug/usr/bin/gnome-shell.debug...done. done. (gdb) I'm not too sure what I am to do from here... I have attached the like valgrind report for F15. @jasper - you can verify that gnome-shell leaks memory on your system? What kind of video card and drivers are you using?
Review of attachment 191596 [details] [review]: Sure.
Attachment 191596 [details] pushed as 32df0e8 - main: Fix small memory leak in main.c
Eek, didn't mean to RESOLVE the bug,
@Jasper - any thoughts for this guy? Did you get a chance to try and repeat this bug on your system? I can say that I just upgraded to Gnome 3.0.2 on my parents machine and this is affecting it on there as well; gnome-shell was over 450 meg after 5 hours :(
Memory leak seems to be on windows resize. Try to open gnome-system-monitor and repeatedly resize window.
gnome shell memory leak is still present in Arch on an intel atom diamondville netbook. after 3 hours of use it's taking up 280mb of ram! I tried to resize a window repeatedly, but nothing.. what to do? I'll check more in detail system monitor to see when it starts to grow..
GNOME Shell 3.0.2 isn't going to be maintained. Duping the other memory related bug. *** This bug has been marked as a duplicate of bug 642652 ***