Bug 977387

Can you reproduce the problem if you disable extensions?

I disabled the extensions then logged in without starting any applications. After 10 hours gnome-shell memory did not grow.

I've started my assortment of applications and will check back on memory use after several hours. If things still seem stable, I'll work on identifying which extension is causing the problem.

If the past is any indication, sensors and system-monitor are good guesses.

Yes. It appears that System-Monitor is the big leaker. I rebooted and started Sensors, Topicons and Windowoverlay-icons last night. After 10 hours gnome-shell grew by only ~100MB, so perhaps there is a smaller leak in Sensors.

Just wanted to add my two cents. My memory grew to 3.4Gigs after leaving my computer on for 2 days. I had to restart the shell to enable functional use of my computer.

I have to say that I do have the sensors extension enabled so I'll try disabling it to see if it is the culprit. 

Fedora 19 x64

In my case, after disabling both suspected offenders, the leak is still present, but much less severe: about 50M every few hours. Disabling them one by one revealed that sensors was much more leaky then system-monitor. With sensors on all my 8G of RAM were garbled in mere half a day.

Anecdotal evidence: after disabling the sensors extension gnome shell stays at a memory usage of roughly 250MB for tens of hours. I don't use the system monitor extension.

fedora 19 x64 with Intel processor i5 third gen no external graphics card

I have this issue too with the sensors extension, will remove it now. Don't have the system monitor one installed.

I have a slightly different system monitor (system-monitor.gmail.com) than the gnome bundled one (systemMonitor.github.com) and it seems to be okay.

To be honest, I don't think it is either sensors or system monitor, but a generic problem with javascript which does a lot of updates. All the extensions are javascripts, so if your javascipt runtime leaks, genome-shell leaks, and the busier the javascript is, the leakier the whole thing is.

It used to be that one needs to re-start the web browser every couple of days, because web sites like facebook, yahoo, google, uses a lot of javascript and leaks. Now it is the whole desktop environment... step backwards.

By the way, it is possible to do:

gnome-shell <other_options> --replace &

to replace the current running gnome-shell with a new one, much like the same trick with the other older window managers. This preserves the work space somewhat, while reclaiming some of the leaked memory, but not all.

(In reply to Hin-Tak Leung from comment #9)
> I have a slightly different system monitor
> (system-monitor.gmail.com) than the gnome bundled one
> (systemMonitor.github.com) and it seems to be
> okay.
> 
> To be honest, I don't think it is either sensors or system monitor, but a
> generic problem with javascript which does a lot of updates. All the
> extensions are javascripts, so if your javascipt runtime leaks, genome-shell
> leaks, and the busier the javascript is, the leakier the whole thing is.
> 
> It used to be that one needs to re-start the web browser every couple of
> days, because web sites like facebook, yahoo, google, uses a lot of
> javascript and leaks. Now it is the whole desktop environment... step
> backwards.

I afraid you might be right: even after disabling the sysmon and the sensors extensions, the mem print of gnome-shell keeps growing at a steady rate of about 200M a day.

Further, I think there are a few other undesirable issues with the design of whole-desktop-as-javascript:

- the sysmon and sensor extensions basically don't work where you need them most: when some background process is eating up CPU time/memory, and causes gnome-shell itself to be sluggish/swapped out - gnome-shell just stop updating the screen, and therefore you don't see the CPU/memory loads when you need to see them most!

- one extension has problem, the whole desktop stops working. Learned it first hand while experimenting with editing classic.json, and doing "gnome-shell --mode=classic --replace &" to reload. The whole thing just freezes if you have a typo. (You end up doing CTRL-ALT-F2 to fix it). With the older applets, you see an error in .xsession-error and the whole thing keeps most of it going.

Is the upstream bug report & patches relevant?
https://bugzilla.gnome.org/show_bug.cgi?id=685513

It is a rather long thread but did go towards 3.8.3 & even mention 3.10, but have some patches in the middle.

Hello,

I am one of the upstream developers of Sensors, a user that had issues with leaking memory memory point out [1] this fedora bug report. I can confirm the behaviour described in this bug and agree with Hin-Tak Leungs comment [2].

My extension allocates/creates a subclass of imports.ui.popupMenu.PopupBaseMenuItem [3] which contains imports.gi.St.Icon and imports.gi.St.Label instances [4], every times it queries the sensors, destroying them before with the destroy() member function [5].

This implementation was written in the assumtion that gjs manages all memory. Is this a wrong assumption? In case it isn't I could condense this to a test case.

(In reply to Hin-Tak Leung from comment #13)
> Is the upstream bug report & patches relevant?

Maybe, as it describes the same behaviour, but I don't use anything clutter related. At least not directly.

[1] https://github.com/xtranophilist/gnome-shell-extension-sensors/issues/85#issuecomment-21147152
[2] https://bugzilla.redhat.com/show_bug.cgi?id=977387#c9
[3] https://github.com/xtranophilist/gnome-shell-extension-sensors/blob/master/src/extension.js#L20
[4] https://github.com/xtranophilist/gnome-shell-extension-sensors/blob/master/src/extension.js#L30
[5] https://github.com/xtranophilist/gnome-shell-extension-sensors/blob/master/src/extension.js#L136

I've seen this for a while too, restarted this machine at work yesterday and it's up to 650MB this morning, baseline seems to be about 78MB.

My suspicion has also been that the choice of javascript for a desktop shell is the main culprit for this issue, given javascript's voracious apatite for memory and terrible reputation in the realm of all things Garbage Collection.

The good thing is that the work around is simple.  maybe I'll write an extension that checks memory gnome-shell memory consuption and notifies when it reaches a user defined threshold ... mostly kidding :)

(In reply to Hin-Tak Leung from comment #10)
> By the way, it is possible to do:
> 
> gnome-shell <other_options> --replace &
> 
> to replace the current running gnome-shell with a new one, much like the
> same trick with the other older window managers. This preserves the work
> space somewhat, while reclaiming some of the leaked memory, but not all.

I've also been able to reload gnome-shell with HUP, starting with version 3.6 (?).  The signal does not work before 3.6, it just kills the shell.  This is handy when the shell starts failing because of memory issues, I drop out to a virtual terminal (eg., Ctrl+Alt+F2) and send the signal to the process, for those who don't know how to do this,

# ps -C gnome-shell -o user,pid
USER       PID
steeve    2859
# kill -HUP 2859

This usually gets me back to about 80MB of memory.

Just an FYI,

You can do the ps and kill in one move using pkill.

# pkill -HUP gnome-shell

Additional notes (not specific for this distro, but HTH):

- restarting the shell sometime makes gnome-terminal windows acts funny, see 
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1215798  (don't think is Ubuntu-specific)

- I upgraded to gnome-shell 3.10 and it seems that the worst of the leakage is gone. The shell was usable after two days continued log-in

(In reply to romano from comment #18)
> - I upgraded to gnome-shell 3.10 and it seems that the worst of the leakage
> is gone. The shell was usable after two days continued log-in

On my 3.10.3 (F20) it's worse than ever. After 2 days uptime it has taken 1.3GB and it's growing fast. Nvidia proprietary drivers.

I can confirm that there is still a memory leak on gnome-shell 3.10.3 (arch linux) with nvidia binary drivers. Starts with 150 MB of ram, and after two days more than a GB of ram in use.

Do you have any extensions enabled?

(In reply to Tapani Mattila from comment #19)
> (In reply to romano from comment #18)
> > - I upgraded to gnome-shell 3.10 and it seems that the worst of the leakage
> > is gone. The shell was usable after two days continued log-in
> 
> On my 3.10.3 (F20) it's worse than ever. After 2 days uptime it has taken
> 1.3GB and it's growing fast. Nvidia proprietary drivers.

Ok --- I can confirm that I see this kind of leakage too. After one day I have VIRT 2.1G and RES 579m --- but what was happening to me with 3.8 was that I have gnome-shell growing past 8G in a few hours and starting swapping (go figure). Now I can live with this. 

Much better now, but yes, still leaking. I use quite a bunch of extensions, yes. 

['aa', 'appindicatorsupport.com', 'CoverflowAltTab.com', 'launch-new-instance.github.com', 'lockkeys', 'places-menu.github.com', 'drive-menu.github.com', 'searchrecentlyused.com', 'temperature@xtranophilist', 'topIcons@gmail.com', 'user-theme.github.com']

PS I am the same romano --- got tangled with a very old bugzilla account.

(In reply to Sam Mingo from comment #17)
> Just an FYI,
> 
> You can do the ps and kill in one move using pkill.
> 
> # pkill -HUP gnome-shell

I have started doing "killall -HUP gnome-shell" (which does the same thing, probably a bit better/more specific than pkill) every day or so, and am seriously tempted to automate it with a crontab entry :-(.

Memory consumption seems to climb to ~700MB resident (3GB virtual) after a day for no good reason. On a 2GB ram machine it is quite noticeable.

You can easily reproduce - just do the following.

1) Start TOP in a TERM Window and order processes by MEM Usage.
2) Start some other applications

3) Keystroke on "Windows Start Button" or Click "Activities"
4) Mouse Click Switch to a arbitrary running application window
5) Keystroke on "Windows Start Button" or Click "Activities"
6) Switch to Term Window with TOP Running
7) Jump to step 3 - Repeat

Watch memory consumption jump 5-10 megs for each window switch.

Gnome Shell Version: 3.10.2.1-16.1
Reproducible: ALWAYS

Best regards

Brian


Brian Carlsen
Carlsen Technologies Aps

ALT+TAB Switching causes general increase of 1-3 megs

Switching between desktops (ctrl-alt-up/down or from the activity view) also produces the same result.

Created attachment 901208 [details]
perf profile of gnome-shell using high CPU/mem

Here is the perf(1) profile for the gnome-shell session using high CPU (> 30% in a dual cpu system) in my case.  This is associated with increased memory usage  - at the time of the perf record top reports ~700 MB RES / 1.2 GB VIRT on a system that has 2 GB - where I usually do 'alt-f2 r' to keep the laptop from running hotter.  But if I don't, memory and cpu usage continue to grow and eventually the session begins to become unresponsive.

Every press on the Menu key (to bring up the shell) increases memory usage with about 2MB. The RES memory is never given back. No extensions loaded. Version Shell: 3.10.2

I meant of course the left windows key to bring up the shell. My apologize

Can confirm this for Fedora 20.

Everytime opening the activities Window increase the memory consumption about 1-3MB ram.

Tested with free and propritary nvidia-drivers.

Can confirm on Fedora 21 (Gnome-Shell 3.14 release).  

This defect spans back to 3.4.  It has gotten better, and is far more pronounced on nVidia proprietary drivers, but still exists on every Gnome I've ever used.  

Has there been any movement on it?

Confirmed, Arch Linux, 3.14

I can also confirm that this on gnome 3.10.4.  The upper corner hotspot, as well as other desktop actions cause the memory usage to increase between 1 and 2Mb.  I am also using the proprietary nvidia drivers.  Specifically, version 343.22.  After a couple days of leaving the computer on standby, the desktop easily consumes 2Gb.  This is really bad.

Same for me with Fedora 20 (gnome-shell-3.10.4-9.fc20) . Every menu keypress increases the RSS by 1-2MB. The only extensions enabled are the default Weather and Places. Using nouveau drivers.

*** Bug 1014265 has been marked as a duplicate of this bug. ***

Same with gnome-shell-3.14.2-1.fc21.x86_64
Memory use is 600MiB after a couple of days.
To monitor I did:

  watch -n1 ps -p $(pidof gnome-shell) -o rss=

I see a leak of at least 4K every time I open/close a window

I do see that the memory decreases asynchronously, and so is probably being garbage collected, but there are leaks as it grows without bound.

This is on a default Fedora 21 install and easily reproducible.

Restarting with "Alt-F2 r" reclaims everything, and starts with about 110MiB usage

*** Bug 814872 has been marked as a duplicate of this bug. ***

bug 888107 overlaps a lot and has useful info

Can we not link this to 685513?  Doing so will all but ensure nothing gets fixed.

I too would love to see this fixed but that's not how things appear to be run on this project.   Once moved on to 'the new version',  unless an update breaks something with disasterous effects, it won't ever get fixed.  It will soon be forgotten and eventually closed with 'WONTFIX'.  Why else would we be seeing all this bug-cleanup/closing now that 21 is releasing without having seen any 'fixes' for this?

This bug started in 19, possibly even 18, and carried into 20. It appears to be, at minimum 3.10, 3.12, and, as shown above, 3.14. I fully expect it to be in Fedora 21 too.  I don't see them getting fixed either.

Really sad.  Gnome is a fantastic desktop.

This upstream bug has useful info:
http://bugzilla.gnome.org/show_bug.cgi?id=685513

While that has been closed upstream, this is
still a significant issue impacting Fedora at least.

folks, these kind of long bugs with different 'reproducers' aren't the best way to get specific bugs fixed. what gets specific bugs fixed is reports (ideally upstream, but downstream works) with *one specific reproducer*, and with valgrind output attached. https://wiki.gnome.org/Valgrind

https://bugzilla.gnome.org/show_bug.cgi?id=737630 is an example (though I do need to go back to it and test the fix :/).

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 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 this bug is closed as described in the policy above.

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.

The version field should be updated.  It applies to Fedora 20 at least (see comments).  I can't update the Version field for this bug or I would.  Maybe only the original reporter can do that?  Or an admin?

as mentioned in c#42, this report just isn't any use to anyone - there's no way anyone can actually debug what leak-y behaviour any one person in this report is seeing, let alone dozens of different people some even running different distros from each other.

please, the  best way to do this is: find a simple and fully reproducible behaviour that triggers something that looks like a leak, then file a bug on the appropriate component upstream *with a valgrind log from reproducing the issue* - https://wiki.gnome.org/Valgrind . You'll need to have the relevant debuginfo packages installed for the valgrind output to be useful, note - something like 'debuginfo-install gnome-shell gtk3 mutter clutter' should get quite a lot, but check the valgrind output for ???-y stuff and install the relevant debuginfos.