Bug 977387 - gnome-shell memory leak
gnome-shell memory leak
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
20
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
:
: 814872 1014265 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-24 08:35 EDT by Kurt Miller
Modified: 2015-12-30 14:35 EST (History)
42 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1181309 (view as bug list)
Environment:
Last Closed: 2015-01-09 15:51:58 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
perf profile of gnome-shell using high CPU/mem (491.35 KB, text/plain)
2014-06-01 07:33 EDT, John Hein
no flags Details

  None (edit)
Description Kurt Miller 2013-06-24 08:35:42 EDT
Description of problem:
gnome-shell continues to grow to use over 2GiB of memory making gnome very unresponsive:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1787 kurt      20   0 4011696 2.471g  38756 S 20.90 16.08 153:15.07 gnome-shell

uptime
 08:26:23 up 1 day, 15:39,  3 users,  load average: 0.13, 0.40, 0.59

Version-Release number of selected component (if applicable):
gnome-shell-3.8.3-2.fc19.x86_64

How reproducible:
Seems to always happen on my workstation. It takes one day for it to build up to over a gigabyte. I'm unsure what steps are needed to cause the problem. I have a typical workstation setup with skype, pidgin, firefox, gnome terminal and evolution running. I have the following extensions installed: Remove accessibility, Sensors, Systemmonitor, Topicons, User themes, Windowoverlay icons and System-monitor.

Please let me know what additional information may be helpful to diagnose further.
Comment 1 Florian Müllner 2013-06-24 08:59:38 EDT
Can you reproduce the problem if you disable extensions?
Comment 2 Kurt Miller 2013-06-25 08:33:08 EDT
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.
Comment 3 Florian Müllner 2013-06-26 05:59:08 EDT
If the past is any indication, sensors and system-monitor are good guesses.
Comment 4 Kurt Miller 2013-06-26 07:42:54 EDT
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.
Comment 5 Mark Harfouche 2013-07-01 17:17:03 EDT
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
Comment 6 Dmitry Burstein 2013-07-13 14:56:41 EDT
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.
Comment 7 Mark Harfouche 2013-07-13 16:09:37 EDT
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
Comment 8 hrafnkellbrimar 2013-07-16 05:34:44 EDT
I have this issue too with the sensors extension, will remove it now. Don't have the system monitor one installed.
Comment 9 Hin-Tak Leung 2013-07-16 13:16:12 EDT
I have a slightly different system monitor (system-monitor@paradoxxx.zero.gmail.com) than the gnome bundled one (systemMonitor@gnome-shell-extensions.gcampax.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.
Comment 10 Hin-Tak Leung 2013-07-16 13:20:58 EDT
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.
Comment 11 Dmitry Burstein 2013-07-16 13:43:13 EDT
(In reply to Hin-Tak Leung from comment #9)
> I have a slightly different system monitor
> (system-monitor@paradoxxx.zero.gmail.com) than the gnome bundled one
> (systemMonitor@gnome-shell-extensions.gcampax.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.
Comment 12 Hin-Tak Leung 2013-07-16 13:59:33 EDT
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.
Comment 13 Hin-Tak Leung 2013-07-16 16:11:10 EDT
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.
Comment 14 Marcel Metz 2013-07-18 05:09:32 EDT
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
Comment 15 Steeve McCauley 2013-09-20 09:26:17 EDT
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 :)
Comment 16 Steeve McCauley 2013-09-20 09:53:22 EDT
(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.
Comment 17 Sam Mingo 2013-12-12 20:57:39 EST
Just an FYI,

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

# pkill -HUP gnome-shell
Comment 18 romano 2014-01-27 12:46:28 EST
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
Comment 19 Tapani Mattila 2014-01-28 16:08:35 EST
(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.
Comment 20 Sander van Veen 2014-01-28 17:00:07 EST
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.
Comment 21 Mark Harfouche 2014-01-28 17:24:13 EST
Do you have any extensions enabled?
Comment 22 Romano Giannetti 2014-01-28 18:33:27 EST
(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@dbfin.com', 'appindicatorsupport@rgcjonas.gmail.com', 'CoverflowAltTab@palatis.blogspot.com', 'launch-new-instance@gnome-shell-extensions.gcampax.github.com', 'lockkeys@vaina.lt', 'places-menu@gnome-shell-extensions.gcampax.github.com', 'drive-menu@gnome-shell-extensions.gcampax.github.com', 'searchrecentlyused@bmh1980de.gmail.com', 'temperature@xtranophilist', 'topIcons@adel.gadllah@gmail.com', 'user-theme@gnome-shell-extensions.gcampax.github.com']

PS I am the same romano --- got tangled with a very old bugzilla account.
Comment 23 Hin-Tak Leung 2014-02-03 06:37:26 EST
(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.
Comment 24 Brian Carlsen 2014-04-09 10:51:46 EDT
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
Comment 25 Brian Carlsen 2014-04-09 10:55:50 EDT
ALT+TAB Switching causes general increase of 1-3 megs
Comment 26 Tapani Mattila 2014-05-15 16:44:09 EDT
Switching between desktops (ctrl-alt-up/down or from the activity view) also produces the same result.
Comment 27 John Hein 2014-06-01 07:33:10 EDT
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.
Comment 28 Michael Gruys 2014-06-21 09:56:11 EDT
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
Comment 29 Michael Gruys 2014-06-21 09:57:14 EDT
I meant of course the left windows key to bring up the shell. My apologize
Comment 30 roidal 2014-10-05 09:39:51 EDT
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.
Comment 31 Chad Rodrigue 2014-10-15 13:03:39 EDT
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?
Comment 32 Chernovsky Oleg 2014-10-25 17:50:57 EDT
Confirmed, Arch Linux, 3.14
Comment 33 sam.petrocelli 2014-10-30 18:58:17 EDT
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.
Comment 34 Tim Jackson 2014-11-18 10:46:09 EST
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.
Comment 35 Pádraig Brady 2014-11-28 23:29:36 EST
*** Bug 1014265 has been marked as a duplicate of this bug. ***
Comment 36 Pádraig Brady 2014-11-28 23:42:33 EST
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
Comment 37 Pádraig Brady 2014-11-28 23:53:08 EST
*** Bug 814872 has been marked as a duplicate of this bug. ***
Comment 38 Pádraig Brady 2014-11-28 23:57:28 EST
bug 888107 overlaps a lot and has useful info
Comment 39 Chad Rodrigue 2014-12-01 08:18:15 EST
Can we not link this to 685513?  Doing so will all but ensure nothing gets fixed.
Comment 40 Chuck Lasher 2014-12-01 08:34:12 EST
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.
Comment 41 Pádraig Brady 2014-12-01 14:44:41 EST
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.
Comment 42 Adam Williamson 2014-12-09 11:49:28 EST
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 :/).
Comment 43 Fedora End Of Life 2015-01-09 13:30:57 EST
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.
Comment 44 John Hein 2015-01-09 13:55:39 EST
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?
Comment 45 Adam Williamson 2015-01-09 15:51:58 EST
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.

Note You need to log in before you can comment on or make changes to this bug.