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 649477 - Slow leak in Shell in current Fedora 15
Slow leak in Shell in current Fedora 15
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.0.x
Other Linux
: Normal major
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-05-05 16:49 UTC by Adam Williamson
Modified: 2013-06-14 16:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Adam Williamson 2011-05-05 16:49:44 UTC
Running current Fedora 15, I've noticed for the last few weeks that Shell leaks memory slowly. It may have been going on longer and I just never noticed because it never stayed up long enough before. :) With a system uptime of nearly 3 days (some of which which will have been spent in suspend), Shell is using 646.5MB of RAM, per gnome-system-monitor. If I kill it, forcing it to restart, it goes down to 30.2MB.

Obviously more data is needed here, but I don't know the best way to provide it; please advise me. Thanks.

gnome-shell-3.0.1-2.fc15.x86_64
Comment 1 Adam Williamson 2011-05-05 16:50:15 UTC
CCing Colin as I saw him active on some other mem leak bugs.
Comment 2 Colin Walters 2011-05-05 17:46:04 UTC
See bug 642652 for a major leak
Comment 3 Adam Williamson 2011-05-05 18:01:25 UTC
is there a quick way to tell if that's what I'm hitting?
Comment 4 Colin Walters 2011-05-05 18:12:54 UTC
(In reply to comment #3)
> is there a quick way to tell if that's what I'm hitting?

No quick way; valgrind is probably your best bet.  Be patient =)
Comment 5 Adam Williamson 2011-05-05 18:23:48 UTC
gneesh, valgrind. I think I'll go with the 'apply patch, rebuild gnome-shell, then see if it's still leaking' approach. =)
Comment 6 Adam Williamson 2011-05-06 15:18:53 UTC
I applied the patch from 642652, rebuilt Shell, rebooted, and on day #2 it's up to over 200MB of memory, so that ain't the one I'm hitting :/
Comment 7 Kirill 2011-06-18 16:23:01 UTC
I see similar behavior on Gentoo x64, with latest available packages from gnome overlay (gnome-base/gnome-shell-3.0.2, gcc 4.6). If you would want more system/compile info from me I will be happy to provide. For me gnome-shell starts from 30M or so and within several days go to 300M
Comment 8 Colin Walters 2011-06-18 20:34:22 UTC
So one issue I see is simply that we aren't garbage collecting enough.  See e.g.

https://bugzilla.mozilla.org/show_bug.cgi?id=664613
Comment 9 Kirill 2011-06-20 23:00:39 UTC
(In reply to comment #8)
> So one issue I see is simply that we aren't garbage collecting enough.  See
> e.g.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=664613

I am not sure it is related to GC of other memory intensive apps. Just for checking it, I have rebooted, login into gnome and left it run without any additional apps. In this test my initial memory usage right after reboot was 59.6M. Over next 13 hours it monotonically grew to 128M... That gives about 5MB/hour memory leak in pretty much gnome alone.
Comment 10 Jasper St. Pierre (not reading bugmail) 2011-06-20 23:19:43 UTC
A valgrind log would be extremely helpful. There's not much we can do other than being psychic.
Comment 11 Kirill 2011-06-20 23:40:34 UTC
(In reply to comment #10)
> A valgrind log would be extremely helpful. There's not much we can do other
> than being psychic.

Will be happy to provide. What is a proper way to run valgrind for debugging gnome-shell? Do I need to recompile gnome shell with debugging enabled? I did a quick search but could not find appropriate instruction set.
Comment 12 Anthony Ruhier 2012-11-12 09:51:33 UTC
There is a way to see quickly the memory leak : click many times on an element of the top bar (like calendar or the username menu) and see the memory consumption of the gnome-shell process increases.

It's working for the activites menu too.
Comment 13 Jean-François Fortin Tam 2012-11-12 17:17:07 UTC
Anthony, in 3.4 I have so far been unable to trigger a visible memory increase by repeatedly opening/closing the calendar menu, the user menu, the app menu or the Activities overlay mode.
Comment 14 Anthony Ruhier 2012-11-12 22:45:41 UTC
I have forgotten to say that I am running on gnome 3.6.1, I had not seen this bug on gnome 3.4 ;)
Comment 15 Florian Müllner 2013-06-14 16:17:31 UTC
There's no valgrind log that would indicate what is/was the problem and we've fixed a lot of leaks since the bug was filed => closing.