Discussed at 2012-12-19 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-19/f18final-blocker-review-6.2012-12-19-17.02.log.txt . Accepted as NTH due to its potential impact on lives.

I'm not sure if it's infinitely reproducible. At least not in my case on an Intel card. Yes, memory usage increases with clicking on panel widgets, I got up to 290 MB, but when I checked it a few hours later, it was down to 270 MB. So it releases occupied memory at some point, hence I don't think it's a memory leak, just too memory hungry.

It never seems to release memory for me on intel (hd4000), I've seen it go to ~500 plus and just stay there. 3.4 never went above ~200 or so, generally stayed around 125.

Now reported as fixed upstream, really hope this makes it into fedora 18!

It's almost certainly too late to make the final build, but it will almost certainly be provided as an update.

As of today (Feb 8) it is still extant in my machine, and a serious problem as it is a work box with limited RAM and when I need to use a VB virtual Win7 (sometimes 3 or 4 times a week) i have to shut the box down, restart and then run the VM first in order have the RAM to successfully and <normally> run the VM (as in with reasonable speed). If I don't the VM drags and eventually crashes. 

In other words: Has this really been fixed, cause it is still a problem for me. Also, when I checked this morning it was using 479 MB for gnome shell, after restart 135 MB.

yeah, will this ever be fixed in fedora?

I left top open in one window, and two other random programs (terminal, and system monitor).  I then simply Alt-tabed between them for a couple minutes, and slowly watched gnome-shell's Resource usage climb from 102 to 287MB (and then level off).  After a couple hours it got to 323Mb, which at 8.6% of my available ram is a problem.  It is getting to the point where I'll have to switch DM because restarting gnome-shell twice a day is excessive.

Using gnome-shell-3.6.3.1-1.fc18.x86_64

F-18, i686, gnome-shell over llvmpipe, been sitting on over 420 MB RES for days now.

F-18, x86_64, gnome shell over i915, been sitting on over 300 MB RES for a while now.

Can we get some updates to get that down to some reasonable level?

(In reply to comment #9)
> Can we get some updates to get that down to some reasonable level?

Probably not I'm afraid. The fix in the upstream bug depends on newer versions of dependencies than F18 provides (at least gjs, possibly gobject-introspection/glib as well).

Actually after some time and while having multiple applications opened, gnome-shell is usign about 190 MB, so it isn't so bad.
I'm on intel i5 with Radeon dedicated.

With another notebook (intel i7 and nvidia graphics adapter), situation seems to be much worse (memory using rise quickly to 400-500 Mb.

It seems to be an hardware-related bug.

@Paolo Leoni, according to the upstream bug its mainly a problem with gnome-shell's javascript interpreter (GJS/Spidermonkey), and people with widely varying hardware seem to be experiencing it.

(In reply to comment #10)
> (In reply to comment #9)
> > Can we get some updates to get that down to some reasonable level?
> 
> Probably not I'm afraid. The fix in the upstream bug depends on newer
> versions of dependencies than F18 provides (at least gjs, possibly
> gobject-introspection/glib as well).

Can't the fixes be backported?

Just for the record, 64-bit box is now at 377 MB RES. The 32-bit box has broken 1/2 GB and is sitting on 550 MB RES now.

I've recently read here that there may be two parts to this bug:

One leak is caused by GJS/Spidermonkkey and should be fixed with gnome 3.8 and the new version of GJS/spidermonkey, and a clutter bindings memory leak that may not be fixed until 3.10:

Oops, forgot to post the link: https://lwn.net/Articles/544877/

this actually seems partially fixed for me already in f18 with all updates. Previously clicking any item in the top panel, going into the overlay, or when my dash-to-dock extension went in and out of autohide the memory would increase.

Now this *only* happens when clicking on the date/time applet in the top panel. clicking volume, networkmanager, status meny, going into overlay, dash-to-dock autohide no longer seem to make the memory usage go up at all. however clicking date/time does make it go up by about 2mb every time and it doesn't get released.

This is still causing problems for me (sure, I can just restart the shell every time when switching windows becomes unbearably slow around 800 MB+, but I really shouldn't have to).

On my F19 laptop (fully uptodate as of yesterday 21/7/2012) I still see a massive memory leak.  It has now after just some 12 hours of uptime grown to almost 3.5GB.

Imagine, it's so bad it has eaten memory beyond the suffering which a 32-bit system can tolerate!

FWIW, I'm running using gnome-classic.

I'm not seeing this "leak" anymore with f19/gnome 3.8 (or at the very least its been made far less severe). The memory usage is still somewhat high compared to say, gnome 3.4, but the memory usage now stays around ~230mb for me, compared to gnome 3.6 where it would notably increase and never release everytime I interacted with the shell, often going 400mb of higher after long uptime.

It now seems to release memory when interacting with the panel, which it didn't do for me prior to fedora 19. For example the calendar applet in the panel used to be the worse offender in f18, clicking it would increase memory usage by a few mb every time and it would never go down after closing it. in f19 clicking it, it only goes up like .1 mb and then releases when I close it, seems much more stable than f18.

Here's my current uptime: 12:58:47 up 1 day, 16:16,  3 users,  load average: 0.17, 0.11, 0.13

And my current shell memory usage: 230.9 mb

3.5Gb after 12 hours seems very highly abnormal to me. Perhaps its some kind of bug with the classic mode, mabye one of the classic mode extensions is leaking memory? Does it do it to you in "regular" gnome-shell?

I'm afraid this leak is not yet fixed.  I can open a terminal, launch 'top' in it and simply WATCH gnome-shell increase VIRT and RES sizes.

Within 36 hours, it will exceed 1.9g RES.  It went from 244meg to 288meg RES in the 15 minutes this machine has been booted.  Granted, not bad but being able to see the VIRT jump from 1899772 to 2030740 is pretty alarming.


I am currently using       gnome-shell-3.8.4-2.fc19.x86_64

I am not using classic mode and did not see this in 3.6

What can I do to help?

Well, for a start, that does not in any way prove that this is the *same* leak. It's a bit impractical to have a single bug for All GNOME Memory Leaks Ever.

There's some discussion on the upstream bug in a similar vein, and some suggestions as to how to get more detailed output there.

https://bugzilla.gnome.org/show_bug.cgi?id=685513

Yeah that doesn't sound like the same bug. The original issue that this bug report describes is memory usage only rising when you interact with gnome-shell, i.e. it would slightly raise memory usage every time you open a menu on the top panel.

If its just wildly leaking like you describe and you can see it just sitting there looking at top its a different type of leak.

And this original bug also existed in 3.6 (in fact it was worse in 3.6 than it is in 3.8), so if you didn't see the issue you are describing in 3.6, then again it sounds like a different issue :)

F-20, x86_64: 450 MB RES taken by gnome-shell.

So, whichever fixes went into 3.10, there is still a problem.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

FWI. 18? 19? 20?  Never seems to have been addressed.  Will it be WONTFIX'd in 19 & 20 when the get tagged EOL too?

The problem is that this is an extremely vague report, and in the wrong place. It's best to file *specific* memory leaks, tied to a valgrind report or at least a clear and clean reproducer, with upstream GNOME.

(In reply to Adam Williamson from comment #28)
> The problem is that this is an extremely vague report, and in the wrong
> place.

Hey, you opened the bug - we just piled on. ;-)

I've never been above self-criticism ;)

it wasn't vague at first, but that's the problem with starting memory leak bugs, they tend to sprawl. i strongly doubt anything anyone's seeing in f19/f20 is the same thing i was seeing in f18.

(In reply to Adam Williamson from comment #30)
> i strongly doubt anything anyone's seeing in
> f19/f20 is the same thing i was seeing in f18.

Generally speaking, I think someone from the Gnome team should look at the long term shell memory consumption.

I have stock F-20 setup on machine I'm writing this on, with one extension enabled (workspace indicator, provided by Fedora) and I don't do anything fancy with my desktop (my background is solid black - that is how boring the whole setup is). Surely, 470 MB RES is way too high (the session has been on for about 5 days). This is on the machine that isn't even wasting memory on llvmpipe (if it matters) - Intel driver. And it has been like this (more or less) since the beginning of Gnome 3.

In a word?  WRONG.

I'm running 19 and if I can run for 4 hours before it goes above 1GB of resident ram and becomes totally non-responsive even to Ctrl-Alt-Backspace that is a LONG TIME.

If anything, can we PLEASE carry this forward somehow?  I've written, and submitted how to duplicate.  Heck, just open top and observe the growth.  No interaction required.

I didn't say no-one was seeing leaks (or something that looks like a leak; sometimes the thing that causes increasing memory usage is not in fact a leak, technically speaking). What I said was:

"i strongly doubt anything anyone's seeing in f19/f20 is the same thing i was seeing in f18."

Bug reports are not talking shops, they're places to work on specific bugs. This report was opened for a particular bug I saw in F18. It's not a General Place To Talk About GNOME RAM Consumption.

(In reply to Adam Williamson from comment #33)
> sometimes the thing that causes increasing memory usage is not in fact a
> leak, technically speaking

Just out of curiosity, what would that (or those) be?

(In reply to Chuck Lasher from comment #32)
> Heck, just open top and observe the growth.  No
> interaction required.

For me, it seems that the big leaks happen when I enter Activities. I guess I don't really see the leaks as much, because I hate going into overview (it should never have been part of the system, IMNSHO), so I can go on for a few days without noticing anything major (with 8 GB of RAM in the system, 1/2 GB is not noticeable and then we usually get a new kernel, which triggers a reboot etc.)

I just pressed the Windows key many times (activate/deactivate overview) on my laptop. Shell soared from 205 MB RES in top to 281 MB RES in top. I could see it grab more and more as I kept pressing the key - totally straightforward to replicate.

I can also trigger leaks by opening the calendar.

As I said before, someone should really have a look at shell's memory use. It should not be hard to see the leaks.

PS. It's been 15 minutes since I did this and no garbage collection has taken place. So, it doesn't seem to be some temporary allocation thing - seems like a real leak.

I just replicated as well by simply pressing the windows key and observing in top as well.

I've already attached valgrind logs of those to the upstream bug, if you look. Seriously, guys. Report upstream. There's where the devs are.

(In reply to Adam Williamson from comment #37)
> Report upstream. There's where the devs are.

I had various success with that approach, to be honest. Anything reported against Evolution, for instance, will be seen and worked on pretty quickly, either in Fedora or upstream. On the other hand, I had this (https://bugzilla.gnome.org/show_bug.cgi?id=719881) open in Fedora and upstream for a couple of months - nobody seems to care either way.

But yeah, OK.

I can't imagine a situation in which they'd pay more attention to a report of a leak in Shell that was filed downstream than upstream. It's just not going to happen.

I only opened this report in the first place as an intentional dupe of an upstream report for freeze exception tracking purposes, because we were in a freeze at the time and I wanted to pull the fix in if it was fixed upstream. It's really just a waste of typing to keep posting about miscellaneous leaks in later versions here.

(In reply to Adam Williamson from comment #39)
> I can't imagine a situation in which they'd pay more attention to a report
> of a leak in Shell that was filed downstream than upstream. It's just not
> going to happen.

I can imagine it (see comment #13) - but it seems that's where it ends - in my imagination. ;-)