Bug 1181309

Created attachment 979334 [details]
Valgrind dump as requested

+++ This bug was initially created as a clone of Bug #977387 +++

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.

--- Additional comment from Florian Müllner on 2013-06-24 08:59:38 EDT ---

Can you reproduce the problem if you disable extensions?

--- Additional comment from Kurt Miller on 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.

--- Additional comment from Florian Müllner on 2013-06-26 05:59:08 EDT ---

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

--- Additional comment from Kurt Miller on 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.

--- Additional comment from Mark Harfouche on 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

--- Additional comment from Dmitry Burstein on 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.

--- Additional comment from Mark Harfouche on 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

--- Additional comment from  on 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.

--- Additional comment from Hin-Tak Leung on 2013-07-16 13:16:12 EDT ---

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.

--- Additional comment from Hin-Tak Leung on 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.

--- Additional comment from Dmitry Burstein on 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.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.

--- Additional comment from Hin-Tak Leung on 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.

--- Additional comment from Hin-Tak Leung on 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.

--- Additional comment from Marcel Metz on 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

--- Additional comment from Steeve McCauley on 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 :)

--- Additional comment from Steeve McCauley on 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.

--- Additional comment from Sam Mingo on 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

--- Additional comment from  on 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

--- Additional comment from Tapani Mattila on 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.

--- Additional comment from Sander van Veen on 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.

--- Additional comment from Mark Harfouche on 2014-01-28 17:24:13 EST ---

Do you have any extensions enabled?

--- Additional comment from Romano Giannetti on 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', '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.

--- Additional comment from Hin-Tak Leung on 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.

--- Additional comment from Brian Carlsen on 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

--- Additional comment from Brian Carlsen on 2014-04-09 10:55:50 EDT ---

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

--- Additional comment from Tapani Mattila on 2014-05-15 16:44:09 EDT ---

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

--- Additional comment from John Hein on 2014-06-01 07:33:10 EDT ---

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.

--- Additional comment from Michael Gruys on 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

--- Additional comment from Michael Gruys on 2014-06-21 09:57:14 EDT ---

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

--- Additional comment from  on 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.

--- Additional comment from Chad Rodrigue on 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?

--- Additional comment from Chernovsky Oleg on 2014-10-25 17:50:57 EDT ---

Confirmed, Arch Linux, 3.14

--- Additional comment from  on 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.

--- Additional comment from Tim Jackson on 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.

--- Additional comment from Pádraig Brady on 2014-11-28 23:29:36 EST ---



--- Additional comment from Pádraig Brady on 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

--- Additional comment from Pádraig Brady on 2014-11-28 23:53:08 EST ---



--- Additional comment from Pádraig Brady on 2014-11-28 23:57:28 EST ---

bug 888107 overlaps a lot and has useful info

--- Additional comment from Chad Rodrigue on 2014-12-01 08:18:15 EST ---

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

--- Additional comment from Chuck Lasher on 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.

--- Additional comment from Pádraig Brady on 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.

--- Additional comment from Adam Williamson (Red Hat) on 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 :/).

--- Additional comment from Fedora End Of Life on 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.

--- Additional comment from John Hein on 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?

--- Additional comment from Adam Williamson (Red Hat) on 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.