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 642652 - Major memory leak on mutter when using gnome-shell
Major memory leak on mutter when using gnome-shell
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.22.x
Other Linux
: Normal critical
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 603580 654269 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-02-18 06:49 UTC by Hellyna Ng
Modified: 2018-10-22 19:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gnome-shell-memory-leak (26.05 KB, image/png)
2011-03-10 23:24 UTC, Hellyna Ng
  Details
patches for leak detection (1.17 KB, application/x-gzip)
2011-03-11 00:42 UTC, Maxim Ermilov
  Details
Valgrind Log (119.75 KB, application/x-xz)
2011-05-04 23:16 UTC, simon
  Details
shell-xfixes-cursor: missing XFree (840 bytes, patch)
2011-05-05 10:13 UTC, Maxim Ermilov
committed Details | Review
valgrind log gnome-shell 3.0.1-3 (60.27 KB, application/x-xz)
2011-05-07 09:02 UTC, siriusb
  Details
Running Gnome-Shell with Valgrind (63.58 KB, application/x-zip-compressed)
2011-10-17 08:20 UTC, Ulukai
  Details
Valgrind log (7.91 KB, application/octet-stream)
2011-10-17 12:58 UTC, elektrobank01
  Details
Full Mutter Valgrind log (28.46 KB, application/octet-stream)
2011-10-17 13:05 UTC, elektrobank01
  Details
memory log amd64 gnome-shell (545.66 KB, text/plain)
2011-10-17 16:50 UTC, Lars Schotte
  Details
the complete gnome-shell memory log (552.72 KB, text/x-log)
2011-10-17 17:39 UTC, Lars Schotte
  Details
memory log i686 gnome-shell (598.58 KB, text/x-log)
2011-10-17 17:44 UTC, Lars Schotte
  Details
Log files (100.00 KB, application/zip)
2011-10-21 19:16 UTC, Ulukai
  Details
util: Fix memory leak in meta_later_remove (1.69 KB, patch)
2011-10-21 19:36 UTC, Jasper St. Pierre (not reading bugmail)
committed Details | Review
prefs: Remove a large section of unused code and squash a memory leak (3.39 KB, patch)
2011-10-21 20:33 UTC, Jasper St. Pierre (not reading bugmail)
reviewed Details | Review
valgrind memcheck and massif outputs (44.19 KB, application/octet-stream)
2012-01-04 12:52 UTC, T.J.Pinkert
  Details
valgrind logs (43.44 KB, application/x-tar)
2016-09-21 20:25 UTC, Christian Stadelmann
  Details
sysprof output with GNOME 3.22 (2.41 MB, application/x-xz)
2016-12-14 05:05 UTC, Jean-François Fortin Tam
  Details
valgrind log gnome-shell 3.20.4 (485.82 KB, application/x-gzip)
2017-01-27 11:15 UTC, Vasilis Liaskovitis
  Details
Fix memory leak in meta_prop_get_values (652 bytes, patch)
2017-02-20 05:22 UTC, xiaoguang wang
none Details | Review
valgrind log with xiaoguang wang's patch applied. (31.79 KB, application/x-xz)
2017-02-21 15:00 UTC, Hussam Al-Tayeb
  Details
x11/xprops: Plug a few memory leaks (2.23 KB, patch)
2017-02-21 15:16 UTC, Rui Matos
committed Details | Review
new valgrind log with num-callers=100 (677.76 KB, application/x-xz)
2017-02-21 15:53 UTC, Hussam Al-Tayeb
  Details
valgrind log with debug mesa (nouveau) (54.91 KB, application/x-xz)
2017-02-21 17:41 UTC, Hussam Al-Tayeb
  Details
valgrind - gjs-1.47.92, gnome-shell-3.23.91 (124.21 KB, application/x-xz)
2017-03-16 22:39 UTC, luke.nukem.jones@gmail.com
  Details
st-texture-cache: Plug some pixbuf refcount leaks on async operations (2.11 KB, patch)
2017-04-07 10:29 UTC, Carlos Garnacho
committed Details | Review
Valgrind log after applying above patch. (110.96 KB, application/x-xz)
2017-04-07 11:40 UTC, Hussam Al-Tayeb
  Details
memcheck output (481.23 KB, application/gzip)
2018-02-26 21:16 UTC, Ralf
  Details

Description Hellyna Ng 2011-02-18 06:49:34 UTC
This bug only manifests itself when gnome-shell is running (with mutter). I tried running mutter alone and that doesn't reproduce the problem. This is a snapshot of top after running the shell for like 7-8 hours.

http://tinypaste.com/4fad70

As you can see the memory took up is ridiculous. 

Reproducing the problem is easy but not obvious. However if you open gnome-system-monitor while running gnome-shell you will see the process mutter increasing its memory for like 0.1-0.2mb with every tick. I've been running the gnome-shell without restarting it for VERY long and hence, the 'damage' accumulated.

Does anybody else have this issue? open top and have a  look at the memory taken up by mutter if ur gnome-shell has been running for a period of time. anything above 150m is ridiculous already.

By the way, the xulrunner version that i am using is Mozilla XULRunner 1.9.2.13 - 20110207153057
Comment 1 Hellyna Ng 2011-03-10 23:24:56 UTC
Created attachment 183104 [details]
gnome-shell-memory-leak

gnome-shell's wm now runs under a different name, but the memory leak is still present. any proposed fixes yet?
Comment 2 Maxim Ermilov 2011-03-11 00:42:01 UTC
Created attachment 183107 [details]
patches for leak detection

> gnome-shell-memory-leak
Wow!! I can't reproduce that. (For me, gnome shell use ~150m after 7 hours)

Can you:
1. apply patches from attachment then run gnome shell (and redirect stdout to file)
2. After same memory usage appear, in looking glass type "Main.describe()"
3. Attach output to this bug

(The file will contain information about alive objects and JS callbacks.)
Comment 3 Hellyna Ng 2011-03-11 06:50:37 UTC
I've been running the gnome-shell for like 5 hours; the current gnome-shell process in question is eating up 1.3 GiB of RAM, and typing Main.describe() in lg yields r(0) = undefined.

I've attached the stdout however; and it's _really_ huge.

I'm providing the link it to my dropbox public folder instead: it's too big for bugzilla.

http://dl.dropbox.com/u/4100676/leakcheck.stdout
Comment 4 Jasper St. Pierre (not reading bugmail) 2011-03-11 07:28:01 UTC
$ curl http://dl.dropbox.com/u/4100676/leakcheck.stdout > hellyna-leaks

running some basic statistics: top five offenders (after removing extraneous whitespace and [object Object])

$ sort hellyna-leaks | uniq -c | sort -n | tail -n5

271  function () { if (this._stateChangedId > 0) { this.app.disconnect(this._stateChangedId); } this._stateChangedId = 0; this._removeMenuTimeout();}

This is from appDisplay.js

271  function () { this._actorDestroyed = true; if (this.actor == this._firstLeaveActor) { this._firstLeaveActor = this._dragOrigParent; } if (this._dragInProgress) { this._cancelDrag(global.get_current_time()); } this.disconnectAll();}

This is from dnd.js

271  function () { this.popupMenu(); this._menu.actor.navigate_focus(null, Gtk.DirectionType.TAB_FORWARD, false);}

This is from appDisplay.js

271  function () { var node = this.actor.get_theme_node(); this._spacing = node.get_length("spacing"); var size; if (this._setSizeManually) { size = this.iconSize; } else { let [found, len] = node.lookup_length("icon-size", false); size = found ? len : ICON_SIZE; } this._createIconTexture(size);}

This is from iconGrid.js: of interesting note is the 'var node = this.actor.get_theme_node();', which after a lazy check with git blame/log, was ever in the source. Not sure if that's a quirk of gjs/libmozjs either.

310  function () { this._removeChild(child);}

This is from popupMenu.js.
Comment 5 Maxim Ermilov 2011-03-11 13:06:49 UTC
> Total objects 3369
It is ok.
> This is from appDisplay.js
> This is from dnd.js
> This is from appDisplay.js
> This is from popupMenu.js.
Not a leaks (just 271 AppWellIcons from applications tab in overview).

So problem not with leaking callbacks.
I think, problem in old(leaking) libraries.
Comment 6 Hellyna Ng 2011-03-19 11:09:23 UTC
I've migrated to linux mint, and I've yet to see a leak :/. I was using arch linux :s
Comment 7 Mao Jianjun 2011-05-04 14:59:00 UTC
I have this problem too. gnome-shell 3.0.1. Is this bug fixed now?
Comment 8 simon 2011-05-04 23:16:19 UTC
Created attachment 187248 [details]
Valgrind Log

I've ran Gnome-shell Through Valgrind if thats any help, theres also a ticket for this on the Arch bug tracker.
https://bugs.archlinux.org/task/24033
Comment 9 Maxim Ermilov 2011-05-05 10:13:43 UTC
Created attachment 187268 [details] [review]
shell-xfixes-cursor: missing XFree

memory returned by XFixesGetCursorImage should be freed after usage.
Comment 10 Colin Walters 2011-05-05 13:02:48 UTC
Review of attachment 187268 [details] [review]:

Looks great to me.
Comment 11 Colin Walters 2011-05-05 13:17:27 UTC
I opened a bug for the next-biggest leak here:
https://bugzilla.gnome.org/show_bug.cgi?id=649457
Comment 12 simon 2011-05-06 04:47:07 UTC
I've applied the xfixes patch and rebuilt and after running it for about 8 hours (of normal usage) memory usage seems to be holding pretty steady at about 127mb
Comment 13 siriusb 2011-05-07 09:02:54 UTC
Created attachment 187413 [details]
valgrind log gnome-shell 3.0.1-3
Comment 14 siriusb 2011-05-07 09:05:00 UTC
Comment on attachment 187413 [details]
valgrind log gnome-shell 3.0.1-3

Still have memory leaks even after applying:
shell-xfixes-cursor: missing XFree
st-private: Fix memory leak

However it's not that bad as used to be, gnome-shell stopped around 130-140 MB, running for 3 hours.
Comment 15 jlquinn 2011-05-22 22:18:59 UTC
My memory usage in gnome-shell:

  PID USER      PR  NI   VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                              
                       1458m 315m  8700 S    2  8.0 179:58.45 gnome-shell

It seems to climb slowly over time.  The size strikes me as excessive.
Comment 16 Jean-François Fortin Tam 2011-06-15 22:44:24 UTC
*** Bug 603580 has been marked as a duplicate of this bug. ***
Comment 17 Kelly Sinnott 2011-07-24 19:57:46 UTC
I have this on gnome-shell 3.0.2. Also running Arch Linux, memory use increases to about 1.5GB, then levels out.
Comment 18 elektrobank01 2011-08-20 12:07:36 UTC
There is a huge memory leak in metacity 2.32.1 too, Ubuntu 11.04 Classic desktop. There are reports from users with up to 2.0gb. of RAM usage.
Comment 19 André Klapper 2011-08-20 15:19:42 UTC
(In reply to comment #18)
> There is a huge memory leak in metacity 2.32.1 too, Ubuntu 11.04 Classic
> desktop. There are reports from users with up to 2.0gb. of RAM usage.

Worth a seperate bug report with valgrind logs.
Comment 20 Ionut Biru 2011-08-20 15:22:45 UTC
metacity 2.32 never existed
Comment 21 elektrobank01 2011-08-20 16:15:00 UTC
@ André Klapper

Source: https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/774740
Comment 22 André Klapper 2011-08-20 16:23:36 UTC
@elektrobank:
That's metacity 2.30 which is obsolete and not maintained anymore in GNOME, plus the link is to a bugtracker of a downstream distribution. If the problem still happens in metacity 2.34 feel free to file a bug report in bugzilla.gnome.org.
Really offtopic for this bug report.
Comment 23 elektrobank01 2011-08-20 16:48:53 UTC
Hmm, there is a variation between different windows themes, so the peak memory usage in "Simple" or "Clearlooks" is about 116MB. after 2-3 hours, while the default "Adwaita" eats up to 290mb. after 2-3 hours.
Comment 24 André Klapper 2011-08-20 18:20:46 UTC
@elektrobank01: Again, unrelated to this report which is about mutter.
Comment 25 Jasper St. Pierre (not reading bugmail) 2011-08-20 18:32:05 UTC
(In reply to comment #24)
> @elektrobank01: Again, unrelated to this report which is about mutter.

I'm assuming elektrobank01 is talking about memory usage of the window themes in GNOME3, not 2.30. And it seems like quite an important thing.

elektrobank01, if you wouldn't mind, could you try hacking up the Adwaita window theme file (should be in /usr/share/themes/Adwaita/metacity-1/metacity-theme-3.xml) and see if you can find anything major that reduces memory usage?
Comment 26 elektrobank01 2011-08-20 18:41:38 UTC
@ André Klapper

There's a leak somewhere in gnome-shell, no one confirmed memory leak in mutter itself.

@ Jasper St. Pierre
I can't do that because I'm not familiar with hacking, I don't even know what xml means.
Comment 27 rockonthemoonfm 2011-10-08 20:47:15 UTC
snome shell memory leak is still present in Arch on an intel atom diamondville netbook.
after 3 hours of use it's taking up 280mb of ram!
what to do?
Comment 28 Jasper St. Pierre (not reading bugmail) 2011-10-08 21:00:57 UTC
*** Bug 654269 has been marked as a duplicate of this bug. ***
Comment 29 graysky 2011-10-09 14:40:53 UTC
I applied the following patch to mutter which helped the problem, but gnome-shell still "leaks" memory on my system, just at a much reduced rate (about 3 MB/h).

http://git.gnome.org/browse/mutter/commit/?id=1b4dce6f843d50fbc9b0fa8f86527788fb0c29d7
Comment 30 Ulukai 2011-10-10 14:24:35 UTC
Using Arch Linux 64 bits, Gnome-Shell 3.2.0-2 and the problem is still present. After a couple of hours, GS eats up all my memory (370 MB at the moment). 

Please change the status (this bug is not "NEW")and fix this soon, it's been open for months.
Comment 31 André Klapper 2011-10-10 14:26:51 UTC
(In reply to comment #30)
> Using Arch Linux 64 bits, Gnome-Shell 3.2.0-2 and the problem is still present.
> After a couple of hours, GS eats up all my memory (370 MB at the moment). 

Also see comment 25 for how to help.

> Please change the status (this bug is not "NEW")

To understand the terminology used in this bugtracker see 
https://bugzilla.gnome.org/page.cgi?id=fields.html#status
Comment 32 Ulukai 2011-10-10 14:34:28 UTC
(In reply to comment #31)
> (In reply to comment #30)
> > Using Arch Linux 64 bits, Gnome-Shell 3.2.0-2 and the problem is still present.
> > After a couple of hours, GS eats up all my memory (370 MB at the moment). 
> 
> Also see comment 25 for how to help.
> 
> > Please change the status (this bug is not "NEW")
> 
> To understand the terminology used in this bugtracker see 
> https://bugzilla.gnome.org/page.cgi?id=fields.html#status

I don't have knowledge of any programming language or XML. But if you send me modified files that need to be tested, I would be glad to help.
Comment 33 graysky 2011-10-10 18:36:05 UTC
@Jonathan - did you patch mutter per comment #29?
Comment 34 Jasper St. Pierre (not reading bugmail) 2011-10-10 19:09:05 UTC
Another way you can help would be running gnome-shell under Valgrind: https://live.gnome.org/Valgrind

Running with massif instead of memcheck should help too. See this page:

http://developer.gnome.org/optimization-guide/stable/optimization-massif-TBL-using-massif.html.en
Comment 35 Jasper St. Pierre (not reading bugmail) 2011-10-10 19:58:34 UTC
(In reply to comment #6)
> I've migrated to linux mint, and I've yet to see a leak :/. I was using arch
> linux :s

Additionally, given this, and that most everyone I know with a giant leak is using Arch Linux, I think it's something out of our stack. There's probably a patch shared among Fedora and Ubuntu/Linux Mint, probably somewhere lower-level like Mesa.

Running massif between Arch and Fedora would be an interesting test.
Comment 36 Ionut Biru 2011-10-10 20:06:46 UTC
hard to say if is a mesa issue because most users who have massive leaks, don't say if they are using open source drivers or nvidia/catalyst
Comment 37 graysky 2011-10-10 20:51:54 UTC
I can confirm the leak with nvidia (proprietary driver) and with nouveau drivers.  The leak rate is the same as indicated by the slope of the line in the following graph:

http://img840.imageshack.us/img840/4926/idle2i.png

Note - the above graph was generated BEFORE the patch to mutter; just to reiterate, the patch (see post 29) plugged most of the memory leak, but gnome-shell still leaking albeit at a much lower rate (0.05 MB/min rather than 2+ MB/min).

This second graph shows the leak AFTER the patch to mutter:

http://s4.postimage.org/b2y7637lx/patch.png

Here are just the linear ranges:

http://s4.postimage.org/b2zftlkxx/linear.png
Comment 38 Ionut Biru 2011-10-10 20:58:52 UTC
(In reply to comment #37)
> I can confirm the leak with nvidia (proprietary driver) and with nouveau
> drivers.  The leak rate is the same as indicated by the slope of the line in
> the following graph:
> 

confirming doesn't help anyone to find the leak. 

recompile glib2/gtk3/mutter/gnome-shell with debug symbols and get valgrind log as stated in comment 34

only with the help of users who have this issue the leaks can be plugged.
Comment 39 alex 2011-10-11 03:28:17 UTC
Is this bug fixed on Gnome3.2?
Comment 40 Ulukai 2011-10-11 07:57:39 UTC
No I haven't patched mutter (never done before), I'm using the latest stable packages in combination with the Nvidia proprietary driver. 

How can I use Valgrind to start Gnome-Shell when logging in? I have never done such thing before and would like to help, but could use some more information.
Comment 41 Matt Gardner 2011-10-11 14:09:51 UTC
(In reply to comment #35)
> Additionally, given this, and that most everyone I know with a giant leak is
> using Arch Linux, I think it's something out of our stack. There's probably a
> patch shared among Fedora and Ubuntu/Linux Mint, probably somewhere lower-level
> like Mesa.
> 
> Running massif between Arch and Fedora would be an interesting test.

I'm using Fedora 15 and GNOME 3.0, and I see the memory leak.  I'm pretty sure I have built in intel graphics, though I'm not sure what driver that means I'm using.  When I restart the shell it uses around 100MB, about 20 minutes later it's now up to 200MB, and it frequently gets to 500MB or so before I restart it (every day or two, generally).

I would like to be of help to track this down, though I don't know too much of what I'm doing - I write lots of code, but it's generally for machine learning kinds of things, never so low level as this.  If you can give me some steps of what to do, I can try to help.
Comment 42 Ulukai 2011-10-15 19:20:59 UTC
I would like to breath some air in this bug report. As I stated before, I would like to be of help, but could use some help generating a log file using valgrind because I have no experience at all and the pages you are referring to are out of date. I start my gnome-session from xinit. 

Also, I have never recompiled or patched anything ever before. If you want the users to help you plugging this, I hope you understand that we don't have your knowledge and that you will be so kind to tell us exactly what to do.
Comment 43 Jasper St. Pierre (not reading bugmail) 2011-10-15 19:26:17 UTC
(In reply to comment #42)
> I would like to breath some air in this bug report. As I stated before, I would
> like to be of help, but could use some help generating a log file using
> valgrind because I have no experience at all and the pages you are referring to
> are out of date. I start my gnome-session from xinit. 
> 
> Also, I have never recompiled or patched anything ever before. If you want the
> users to help you plugging this, I hope you understand that we don't have your
> knowledge and that you will be so kind to tell us exactly what to do.

Do note that there is a major memory leak in Mutter 3.2.0 that is fixed in git, and will be released in 3.2.1.

If you still want to help us, you should be able to use Valgrind. I run it like this:

 $ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full gnome-shell --replace

If you want to use massif:

 $ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=massif --depth=5  --alloc-fn=g_malloc --alloc-fn=g_realloc --alloc-fn=g_try_malloc --alloc-fn=g_malloc0 --alloc-fn=g_mem_chunk_alloc gnome-shell --replace
Comment 44 Ionut Biru 2011-10-15 19:28:42 UTC
some debugging packages are here: http://pkgbuild.com/~ioni/debug/ you can skip installing gdm or metacity.
Comment 45 Lars Schotte 2011-10-16 23:20:33 UTC
Fedora 16 gnome-shell 3.2 problem still exists. at least on 64 bit amd64 architecture.

so it doesnt look like this is going to be fixed.

GNOME Shell 3.2.0
Comment 46 Jasper St. Pierre (not reading bugmail) 2011-10-16 23:43:12 UTC
(In reply to comment #45)
> Fedora 16 gnome-shell 3.2 problem still exists. at least on 64 bit amd64
> architecture.
> 
> so it doesnt look like this is going to be fixed.
> 
> GNOME Shell 3.2.0

Running Massif or Valgrind on GNOME Shell or raw mutter will help us get it fixed. We cannot reproduce the bug ourselves, so we're asking for your help to find memory leaks.
Comment 47 Lars Schotte 2011-10-16 23:49:43 UTC
well, i have read it in the meantime and i am running valgrind on all my machines, so 64bit and 32bit logs will be available soon.

i am "massif"ly on it ;-)
Comment 48 Ulukai 2011-10-17 08:20:22 UTC
Created attachment 199178 [details]
Running Gnome-Shell with Valgrind

(In reply to comment #43)
> (In reply to comment #42)
> > I would like to breath some air in this bug report. As I stated before, I would
> > like to be of help, but could use some help generating a log file using
> > valgrind because I have no experience at all and the pages you are referring to
> > are out of date. I start my gnome-session from xinit. 
> > 
> > Also, I have never recompiled or patched anything ever before. If you want the
> > users to help you plugging this, I hope you understand that we don't have your
> > knowledge and that you will be so kind to tell us exactly what to do.
> 
> Do note that there is a major memory leak in Mutter 3.2.0 that is fixed in git,
> and will be released in 3.2.1.
> 
> If you still want to help us, you should be able to use Valgrind. I run it like
> this:
> 
>  $ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck
> --leak-check=full gnome-shell --replace
> 
> If you want to use massif:
> 
>  $ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=massif --depth=5 
> --alloc-fn=g_malloc --alloc-fn=g_realloc --alloc-fn=g_try_malloc
> --alloc-fn=g_malloc0 --alloc-fn=g_mem_chunk_alloc gnome-shell --replace

Thank you for the howto. I used your command for valgrind this weekend and include the log file in this post. 

From the moment I started valgrind, my system kinda froze. It lost all responsiveness but I tried to move some windows around and get in and out the activity view. I let it run for 15 minutes or so and then I TTY-ed out of my session and rebooted the system. 

AMD Phenom II 3.6 GHz
6 GB DDR3 RAM
Nvidia GTX 560 TI with proprietary driver
Arch Linux 64-bits, all latest packages and only stable repos.
Comment 49 Jasper St. Pierre (not reading bugmail) 2011-10-17 11:45:55 UTC
Apologies, but this log isn't too useful. I should have provided more information. Install debug info for your packages -- Arch Linux doesn't provide split debug info, but Ionut Biru gave some packages above.

Additionally, using a suppressions file may reveal the more fruitful traces.

 $ wget http://git.gnome.org/browse/clutter/plain/tests/data/clutter-1.0.suppressions
 $ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck
 --leak-check=full --suppressions=clutter-1.0.suppressions gnome-shell --replace
Comment 50 elektrobank01 2011-10-17 12:58:15 UTC
Created attachment 199200 [details]
Valgrind log

Here is the output from: valgrind --tool=memcheck mutter
Comment 51 elektrobank01 2011-10-17 13:05:11 UTC
Created attachment 199201 [details]
Full Mutter Valgrind log

Output from: valgrind --leak-check=full mutter
Comment 52 Jasper St. Pierre (not reading bugmail) 2011-10-17 13:06:28 UTC
> Window manager warning: Screen 0 on display ":0" already has a window manager; try using the --replace option to replace the current window manager.

You need to replace the current window manager instead of just running it. Use the instructions I gave above, but substitute "mutter" for "gnome-shell" where ever you see it. Make sure to install debuginfo packages.

At this point, I think I've combed through enough memcheck logs, so some Massif ones would be helpful.
Comment 53 elektrobank01 2011-10-17 13:36:50 UTC
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck mutter
 --leak-check=full mutter--suppressions=mutter.suppressions mutter --replace

Command generates same output as above. And I don't know how to install debuginfo packages.
Comment 54 Ionut Biru 2011-10-17 13:38:23 UTC
(In reply to comment #53)
> G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck mutter
>  --leak-check=full mutter--suppressions=mutter.suppressions mutter --replace
> 
> Command generates same output as above. And I don't know how to install
> debuginfo packages.

for i686 use this link: http://pkgbuild.com/~ioni/debug/i686/
for x86_64 use this link http://pkgbuild.com/~ioni/debug/x86_64/

# pacman -U link/to/package1 link/to/package2 etc

then relogin
Comment 55 Peter Robinson 2011-10-17 13:43:34 UTC
I would suggest reviewing clutter 1.8.2. It has the following fix:

- Plug memory leaks in ClutterBoxLayout The list of children retrieved from the container was not being freed in each size negotiation cycle.

http://ftp.gnome.org/pub/GNOME/sources/clutter/1.8/clutter-1.8.2.news
Comment 56 Jasper St. Pierre (not reading bugmail) 2011-10-17 13:45:14 UTC
(In reply to comment #53)
> G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck mutter
>  --leak-check=full mutter--suppressions=mutter.suppressions mutter --replace

"mutter--suppressions" is not a valid command line argument. There's an extraneous "mutter" after --tool=memcheck. I've never seen a mutter.suppressions file. Please:

1. Grab the suppressions file:
 $ wget
http://git.gnome.org/browse/clutter/plain/tests/data/clutter-1.0.suppressions

2. Run with memcheck.
 $ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck
 --leak-check=full --suppressions=clutter-1.0.suppressions mutter
--replace

3. Run with massif.
 $ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=massif --depth=5 
--alloc-fn=g_malloc --alloc-fn=g_realloc --alloc-fn=g_try_malloc
--alloc-fn=g_malloc0 --alloc-fn=g_mem_chunk_alloc --suppressions=clutter-1.0.suppressions mutter --replace

(In reply to comment #55)
> I would suggest reviewing clutter 1.8.2. It has the following fix:
> 
> - Plug memory leaks in ClutterBoxLayout The list of children retrieved from the
> container was not being freed in each size negotiation cycle.
> 
> http://ftp.gnome.org/pub/GNOME/sources/clutter/1.8/clutter-1.8.2.news

We do not use ClutterBoxLayout.
Comment 57 elektrobank01 2011-10-17 15:31:53 UTC
This is to complicated. I mean, you can't find the cause of the leak for almost year and a half? Please, there are 4-5 packages that has to be tested, clutter, mutter, gtk, libglib etc.
Comment 58 Jasper St. Pierre (not reading bugmail) 2011-10-17 15:35:42 UTC
(In reply to comment #57)
> This is to complicated. I mean, you can't find the cause of the leak for almost
> year and a half? Please, there are 4-5 packages that has to be tested, clutter,
> mutter, gtk, libglib etc.

Software is difficult. We're trying. I see stable memory usage here, so I need logs from someone who actually has the problem to be able to track it down.
Comment 59 elektrobank01 2011-10-17 15:43:56 UTC
Sorry, I desperately trying to do a test but I can't for some reason. I'm getting errors and "no command found" dialogues. 
I have nVidia Geforce Go 7330 with default nouveau driver if might help.
Fedora 15 i686
Comment 60 elektrobank01 2011-10-17 15:45:38 UTC
typo GeForce Go 7300
Comment 61 Lars Schotte 2011-10-17 16:50:40 UTC
Created attachment 199230 [details]
memory log amd64 gnome-shell

here is that log it produced using memcheck on amd64
Comment 62 Lars Schotte 2011-10-17 16:54:20 UTC
seems to be that f*** shader effect, because everytime that message comes, (gnome-shell:1898): Clutter-WARNING **: Unable to use the ShaderEffect: the graphics hardware or the current GL driver does not implement support for the GLSL shading language.
my RAM usage goes UP !!!

and never drops, so when it comes 1000 times, then i have like 1000 times 100mb more and that will end up in not enough memory, as long as i have only 2 GB
Comment 63 Lars Schotte 2011-10-17 16:59:55 UTC
well ... i reproduced it, my memory EXPLODES AGAIN.

so i will be gnone in a few minutes, but i am still looking into the log and there is NOTHING in there. the last messages are about that he can not create the sading effects, what is NOT TRUE because I HAVE SHADES and ALL EFFECTS. so that warning doesnt correspond to the reality. however. as long as it is the last message before my memory is going to be filled up with s*** . the possibility is high that this may be the reason.

btw. firefox 7 could have something to do with this as well as long as this happens only when i am running firefox with a lot of java s*** inside.
Comment 64 Peter Robinson 2011-10-17 17:07:48 UTC
(In reply to comment #62)
> seems to be that f*** shader effect, because everytime that message comes,
> (gnome-shell:1898): Clutter-WARNING **: Unable to use the ShaderEffect: the
> graphics hardware or the current GL driver does not implement support for the
> GLSL shading language.
> my RAM usage goes UP !!!
> 
> and never drops, so when it comes 1000 times, then i have like 1000 times 100mb
> more and that will end up in not enough memory, as long as i have only 2 GB

If your running F-16 as installed (not Live Image) I suggest grabbing the clutter/cogl 1.8.2 builds just submitted as updates as they both have fixes for memory leaks.
Comment 65 Lars Schotte 2011-10-17 17:17:38 UTC
(In reply to comment #64)
> (In reply to comment #62)
> > seems to be that f*** shader effect, because everytime that message comes,
> > (gnome-shell:1898): Clutter-WARNING **: Unable to use the ShaderEffect: the
> > graphics hardware or the current GL driver does not implement support for the
> > GLSL shading language.
> > my RAM usage goes UP !!!
> > 
> > and never drops, so when it comes 1000 times, then i have like 1000 times 100mb
> > more and that will end up in not enough memory, as long as i have only 2 GB
> 
> If your running F-16 as installed (not Live Image) I suggest grabbing the
> clutter/cogl 1.8.2 builds just submitted as updates as they both have fixes for
> memory leaks.

well, i will see first if something is there. in what repos did you submit it? fedora or updates-testing?

what i did first here, is that i have gone into the fallback mode and see if the problem occurs here as well in the meantime.
Comment 66 Lars Schotte 2011-10-17 17:35:12 UTC
to me it looks like this:

Name        : clutter
Arch        : x86_64
Version     : 1.8.0
Release     : 1.fc16
Size        : 2.6 M
Repo        : installed
From repo   : fedora
Comment 67 Lars Schotte 2011-10-17 17:36:43 UTC
yum update
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Update Process
No Packages marked for Update

yum repolist
Loaded plugins: langpacks, presto, refresh-packagekit
repo id                                                                        repo name                                                                                    status
adobe-linux-x86_64                                                             Adobe Systems Incorporated                                                                        2
fedora                                                                         Fedora 16 - x86_64                                                                           25,013
rpmfusion-free-rawhide                                                         RPM Fusion for Fedora Rawhide - Free                                                            383
rpmfusion-nonfree-rawhide                                                      RPM Fusion for Fedora Rawhide - Nonfree                                                         166
updates                                                                        Fedora 16 - x86_64 - Updates                                                                      0
repolist: 25,564
Comment 68 Lars Schotte 2011-10-17 17:39:41 UTC
Created attachment 199234 [details]
the complete gnome-shell memory log

well here we have a complete log. i had to resart - and that is the end of the log, because my memory was going to be filled up - bug has been reproduced.
Comment 69 Lars Schotte 2011-10-17 17:44:24 UTC
Created attachment 199235 [details]
memory log i686 gnome-shell

here we have a log also till the memory was going to be filled up on i686.

on i686 here we dont have that extreme pace at what the memory usage rised, but it was still noticable, that it was going to be more and more
Comment 70 Jasper St. Pierre (not reading bugmail) 2011-10-19 17:13:08 UTC
(In reply to comment #62)
> seems to be that f*** shader effect, because everytime that message comes,
> (gnome-shell:1898): Clutter-WARNING **: Unable to use the ShaderEffect: the
> graphics hardware or the current GL driver does not implement support for the
> GLSL shading language.
> my RAM usage goes UP !!!

This is a memory leak that's fixed in mutter git.

http://git.gnome.org/browse/mutter/commit/?id=1b4dce6f843d50fbc9b0fa8f86527788fb0c29d7
Comment 71 Lars Schotte 2011-10-19 17:34:39 UTC
well, i was already told to wait for the new version that is already comitted to the fedora repository, but it takes some time to get through the testing process.

so i am waiting for that update to come. i the meantime i do nothing because, it looks like everything that had to be done was done.

the question is, will the problem be gone after that update, or will a new memory leak open up.

i am curious
Comment 72 Ulukai 2011-10-21 09:06:37 UTC
I just installed Gnome 3.2.1 (Arch Linux 64-bit) with the new Gnome-Shell 3.2.1 and Mutter 3.2.1 and after a few hours GS memuse was 229 MB again... :-( 

Will try to do what Jasper asked (Valgrind and Massif) tonight to provide something useful.
Comment 73 Peter Robinson 2011-10-21 09:23:41 UTC
> so i am waiting for that update to come. i the meantime i do nothing because,
> it looks like everything that had to be done was done.

The clutter/cogl updates have been in updates-testing since the 18th. the mutter update is in updates-testing now.
Comment 74 Lars Schotte 2011-10-21 12:22:53 UTC
(In reply to comment #72)
> I just installed Gnome 3.2.1 (Arch Linux 64-bit) with the new Gnome-Shell 3.2.1
> and Mutter 3.2.1 and after a few hours GS memuse was 229 MB again... :-( 
> 
> Will try to do what Jasper asked (Valgrind and Massif) tonight to provide
> something useful.

well that would be a catastrophic scenario if it is true. did you check your clutter version? are you sure that clutter still is not 1.8.0 version, like mine is? because i also have some 3.2.1 packages, but that doesnt mean anything.
Comment 75 Lars Schotte 2011-10-21 12:24:43 UTC
(In reply to comment #73)
> > so i am waiting for that update to come. i the meantime i do nothing because,
> > it looks like everything that had to be done was done.
> 
> The clutter/cogl updates have been in updates-testing since the 18th. the
> mutter update is in updates-testing now.

well, mutter 3.2.1 and clutter 1.8.2 just came in to fedora repository, i am updating as i write.

let's see then. it all came in today.
Comment 76 Ulukai 2011-10-21 12:34:42 UTC
(In reply to comment #74)
> (In reply to comment #72)
> > I just installed Gnome 3.2.1 (Arch Linux 64-bit) with the new Gnome-Shell 3.2.1
> > and Mutter 3.2.1 and after a few hours GS memuse was 229 MB again... :-( 
> > 
> > Will try to do what Jasper asked (Valgrind and Massif) tonight to provide
> > something useful.
> 
> well that would be a catastrophic scenario if it is true. did you check your
> clutter version? are you sure that clutter still is not 1.8.0 version, like
> mine is? because i also have some 3.2.1 packages, but that doesnt mean
> anything.

I'm pretty sure it's clutter 1.8.2 + mutter 3.2.1 + Gnome-Shell 3.2.1 since they got in the repository at the same time and before my time of updating. Will check when I'm home and then I can provide more logs.
Comment 77 Lars Schotte 2011-10-21 12:52:41 UTC
(In reply to comment #76)
> (In reply to comment #74)
> > (In reply to comment #72)
> > > I just installed Gnome 3.2.1 (Arch Linux 64-bit) with the new Gnome-Shell 3.2.1
> > > and Mutter 3.2.1 and after a few hours GS memuse was 229 MB again... :-( 
> > > 
> > > Will try to do what Jasper asked (Valgrind and Massif) tonight to provide
> > > something useful.
> > 
> > well that would be a catastrophic scenario if it is true. did you check your
> > clutter version? are you sure that clutter still is not 1.8.0 version, like
> > mine is? because i also have some 3.2.1 packages, but that doesnt mean
> > anything.
> 
> I'm pretty sure it's clutter 1.8.2 + mutter 3.2.1 + Gnome-Shell 3.2.1 since
> they got in the repository at the same time and before my time of updating.
> Will check when I'm home and then I can provide more logs.

well, i ll monitor it now as well, but i do not run it in debug mode as long as the memory doesnt begin to rise unreasonably.
Comment 78 Lars Schotte 2011-10-21 15:19:19 UTC
well, i was monitoring that after the upgrade to clutter 1.8.2 so the new version is in place but the memory consumption of gnome-shell is still rising.

the pace at which it is rising its memory consumption is BY FAR not that fast, but it is getting more and more and that is not reasonable. i have and icrease of say 10% by one hour. so maybe in a day it quadruples.

i am still on it, but it looks like there is somewehere another memory leak out there. when it rises critically i will beginn to collect some logs/debug messages.

let's see what happens. firts it was constantly at 60 MB, then after a while of idling it begun to rise and first it was at 64 MB then 70 MB and now 73 MB ... it seems like the pace at which it rises its consumption is not linear but expenential, exactly like before.

well . 73 MB is not the world but the time in which it rised to this amount is frightening when you take into account that before it was on 60 MB constantly for SOME hours and now it takes more and more w/o any reason.
Comment 79 graysky 2011-10-21 18:50:30 UTC
@Lars - I too did this, see comment #29.
Comment 80 Ulukai 2011-10-21 19:16:59 UTC
Created attachment 199694 [details]
Log files
Comment 81 Ulukai 2011-10-21 19:18:05 UTC
I took some time to download the suppressions file as suggested in comment #49 and install the debug packages for Arch Linux amd64 as provided in this thread. 

In my zipfile you will find the logs of my tests with memcheck and massif. Some tests were done before installing the debug packages, then there is no "debug" in the filename. When there is a number "1" in the filename, it is done with memcheck. Number "2" means Massif. 

Hopefully this means anything to you.
Comment 82 Lars Schotte 2011-10-21 19:23:28 UTC
(In reply to comment #79)
> @Lars - I too did this, see comment #29.

well, then we are not the only ones.
Comment 83 Jasper St. Pierre (not reading bugmail) 2011-10-21 19:36:12 UTC
Created attachment 199696 [details] [review]
util: Fix memory leak in meta_later_remove

We never destroy the later list that's added by meta_later_add.

==4289== 16 bytes in 1 blocks are definitely lost in loss record 1,632 of 7,258
==4289==    at 0x4C2640D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4289==    by 0x5178D9F: standard_malloc (gmem.c:88)
==4289==    by 0x5178E37: g_malloc (gmem.c:164)
==4289==    by 0x51924B5: g_slice_alloc (gslice.c:842)
==4289==    by 0x5194521: g_slist_insert_sorted_real (gslist.c:900)
==4289==    by 0x519465A: g_slist_insert_sorted (gslist.c:957)
==4289==    by 0x4EA609A: meta_later_add (util.c:876)
==4289==    by 0x4E9C330: meta_screen_queue_workarea_recalc (screen.c:2640)
==4289==    by 0x4E9A360: update_num_workspaces (screen.c:1646)
==4289==    by 0x4E99026: meta_screen_new (screen.c:924)
==4289==    by 0x4E7AB51: meta_display_open (display.c:803)
==4289==    by 0x4E9168E: meta_run (main.c:552)



Thanks. I found this with your logs.
Comment 84 Jasper St. Pierre (not reading bugmail) 2011-10-21 19:45:24 UTC
Comment on attachment 199696 [details] [review]
util: Fix memory leak in meta_later_remove

Attachment 199696 [details] pushed as 7f9472a - util: Fix memory leak in meta_later_remove


Pushed patch after IRC review. Leaving bug open as there's probably plenty more in that log.
Comment 85 Lars Schotte 2011-10-21 19:47:53 UTC
(In reply to comment #83)
> Created an attachment (id=199696) [details] [review]
> util: Fix memory leak in meta_later_remove
> 
> We never destroy the later list that's added by meta_later_add.
> 
> ==4289== 16 bytes in 1 blocks are definitely lost in loss record 1,632 of 7,258
> ==4289==    at 0x4C2640D: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==4289==    by 0x5178D9F: standard_malloc (gmem.c:88)
> ==4289==    by 0x5178E37: g_malloc (gmem.c:164)
> ==4289==    by 0x51924B5: g_slice_alloc (gslice.c:842)
> ==4289==    by 0x5194521: g_slist_insert_sorted_real (gslist.c:900)
> ==4289==    by 0x519465A: g_slist_insert_sorted (gslist.c:957)
> ==4289==    by 0x4EA609A: meta_later_add (util.c:876)
> ==4289==    by 0x4E9C330: meta_screen_queue_workarea_recalc (screen.c:2640)
> ==4289==    by 0x4E9A360: update_num_workspaces (screen.c:1646)
> ==4289==    by 0x4E99026: meta_screen_new (screen.c:924)
> ==4289==    by 0x4E7AB51: meta_display_open (display.c:803)
> ==4289==    by 0x4E9168E: meta_run (main.c:552)
> 
> 
> 
> Thanks. I found this with your logs.

OK, so that means that there is a list created every ... say a few seconds ... and that is not used to overwrite the old one, but does add that new list to the old one?

did i understand it right?
Comment 86 Lars Schotte 2011-10-21 19:48:29 UTC
(In reply to comment #84)
> (From update of attachment 199696 [details] [review])
> Attachment 199696 [details] pushed as 7f9472a - util: Fix memory leak in
> meta_later_remove
> 
> 
> Pushed patch after IRC review. Leaving bug open as there's probably plenty more
> in that log.

well, thats probably the best idea ;-)
Comment 87 Jasper St. Pierre (not reading bugmail) 2011-10-21 19:51:35 UTC
The bug is that g_slist_remove_link doesn't actually free the list item, just removes it from the list. GSList is a linked list. g_slist_delete_link removes and frees the link.
Comment 88 Lars Schotte 2011-10-21 20:13:49 UTC
(In reply to comment #87)
> The bug is that g_slist_remove_link doesn't actually free the list item, just
> removes it from the list. GSList is a linked list. g_slist_delete_link removes
> and frees the link.

well, that would be a bug in memory management. but is it realistic that such thing could be responsible for some MB of data? or will there be some more bugs?

i am wondering how is it possible that i did not encounter such bugs before, knowing that memory management mistakes are the most often to happen.
Comment 89 Jasper St. Pierre (not reading bugmail) 2011-10-21 20:33:57 UTC
Created attachment 199701 [details] [review]
prefs: Remove a large section of unused code and squash a memory leak

==5281== 45 (16 direct, 29 indirect) bytes in 1 blocks are definitely lost in loss record 5,148 of 11,144
==5281==    at 0x4C2640D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5281==    by 0x6E49D9F: standard_malloc (gmem.c:88)
==5281==    by 0x6E49E37: g_malloc (gmem.c:164)
==5281==    by 0x6E634B5: g_slice_alloc (gslice.c:842)
==5281==    by 0x514EF0E: meta_prefs_override_preference_location (prefs.c:1244)
==5281==    by 0x402AAA: shell_prefs_init (main.c:294)
==5281==    by 0x402EFC: main (main.c:536)



Another leak from the logs.
Comment 90 Jasper St. Pierre (not reading bugmail) 2011-10-21 20:44:12 UTC
I don't know how long Jonathan ran gnome-shell under valgrind for, and I didn't do the calculations, but I would expect it would amount to around 1MB in those logs. We call meta_later_add quite often in the Shell, much more often than raw Metacity or Mutter, and a leak is a leak, even if it's a pre-existing one.

Unfortunately, Jonathan, your Massif leaks didn't come out too well, and I don't know why. I'll try running Massif later and post my experiences on the bug.
Comment 91 Ulukai 2011-10-22 10:34:53 UTC
Glad I could help. I ran all my tests for a few minutes because my desktop becomes unusably slow. In some cases Gnome just crashed and gave me the login screen. I tried to do some actions (opening applications, moving windows around,opening a site in a browser, ...) when Gs didn't crash however. 

I noticed that massif gave weird logs too :-) Could it be because I used the clutter suppressions file for every command? Do I need to use another suppressions file for every other app that I'm testing with valgrind?
Comment 92 Lars Schotte 2011-10-22 10:52:01 UTC
(In reply to comment #91)
> Glad I could help. I ran all my tests for a few minutes because my desktop
> becomes unusably slow. In some cases Gnome just crashed and gave me the login
> screen. I tried to do some actions (opening applications, moving windows
> around,opening a site in a browser, ...) when Gs didn't crash however. 
> 
> I noticed that massif gave weird logs too :-) Could it be because I used the
> clutter suppressions file for every command? Do I need to use another
> suppressions file for every other app that I'm testing with valgrind?

thanks for your help. is massif better than valngrid or what it calls itself?

i will run memcheck's next week.
Comment 93 Ulukai 2011-10-24 20:21:04 UTC
About the weird Massif logs: could it be because I used the
clutter suppressions file for every command? Do I need to use another
suppressions file for every other app that I'm testing with valgrind?

Could I give more useful logs with another suppressions file or command? Or do you think you plugged most of the memory leaks by now? I ask because Gnome-Shell is running at 400 MB again and dragging windows is getting slow... I would appreciate a patched version soon and would be glad to help if you need more results.
Comment 94 Lars Schotte 2011-10-24 20:46:36 UTC
(In reply to comment #93)
> About the weird Massif logs: could it be because I used the
> clutter suppressions file for every command? Do I need to use another
> suppressions file for every other app that I'm testing with valgrind?
> 
> Could I give more useful logs with another suppressions file or command? Or do
> you think you plugged most of the memory leaks by now? I ask because
> Gnome-Shell is running at 400 MB again and dragging windows is getting slow...
> I would appreciate a patched version soon and would be glad to help if you need
> more results.

i think more than more results, we need more people that are on it.

but it is hard to convince someone to get into, because everyone steps down from gnome and moves to KDE or XFCE.

but they dont realize that KDE was here before.
Comment 95 Ulukai 2011-10-25 07:43:06 UTC
I've been trying KDE 3, never liked it. 
Tried KDE 4.0, never liked it. Tried, 4.2, 4.4, 4.7 and still don't like it. I find it very buggy. 

I do like its customizability and I think Gnome devs need to work hard on that for 3.4 and 3.6. It should be priority now before more features. Everyone I know who uses Gnome 3 thinks exactly the same. What there is now is a very good base, but we need to be able to tweak our desktop to our liking.

That aside, the memory leak bug is REALLY annoying. I'm checking Arch repos for new packages every day to get it out of my system... :-(
Comment 96 Peter Robinson 2011-10-25 08:18:29 UTC
(In reply to comment #95)
> I've been trying KDE 3, never liked it. 
> Tried KDE 4.0, never liked it. Tried, 4.2, 4.4, 4.7 and still don't like it. I
> find it very buggy. 
> 
> I do like its customizability and I think Gnome devs need to work hard on that
> for 3.4 and 3.6. It should be priority now before more features. Everyone I
> know who uses Gnome 3 thinks exactly the same. What there is now is a very good
> base, but we need to be able to tweak our desktop to our liking.
> 
> That aside, the memory leak bug is REALLY annoying. I'm checking Arch repos for
> new packages every day to get it out of my system... :-(

This is a bug for technical discussion of this bug. Not a social commentary of various DEs.
Comment 97 Jasper St. Pierre (not reading bugmail) 2011-10-25 08:51:51 UTC
(In reply to comment #95)
> That aside, the memory leak bug is REALLY annoying. I'm checking Arch repos for
> new packages every day to get it out of my system... :-(

https://live.gnome.org/ThreePointThree

3.2.2 is happening on November 16th.
Comment 98 Ulukai 2011-10-25 08:59:05 UTC
(In reply to comment #97)
> (In reply to comment #95)
> > That aside, the memory leak bug is REALLY annoying. I'm checking Arch repos for
> > new packages every day to get it out of my system... :-(
> 
> https://live.gnome.org/ThreePointThree
> 
> 3.2.2 is happening on November 16th.

Thank you.
Comment 99 Colin Walters 2011-10-26 14:50:49 UTC
Review of attachment 199701 [details] [review]:

Why is this unused?  The comment says:

/* Merge identical overrides, this isn't an error */

And we're clearly calling meta_prefs_override_preference_location() from gnome-shell.
Comment 100 Lars Schotte 2011-10-26 17:46:00 UTC
well, i am stuck now.

after the second, so not the first one, the one with mutter 1.8.2, update, i am not able to reproduce the bug. first i had the big leak, then after the update to mutter 1.8.2, it went slower and less critical, but there was an update in between, and i am now on 70 MB of RAM for gnome-shell for a long time now.

it's getting hard to find the remeaning leaks now.
Comment 101 Ulukai 2011-10-26 19:11:35 UTC
(In reply to comment #100)
> well, i am stuck now.
> 
> after the second, so not the first one, the one with mutter 1.8.2, update, i am
> not able to reproduce the bug. first i had the big leak, then after the update
> to mutter 1.8.2, it went slower and less critical, but there was an update in
> between, and i am now on 70 MB of RAM for gnome-shell for a long time now.
> 
> it's getting hard to find the remeaning leaks now.

So which update fixed it for you?
Comment 102 Lars Schotte 2011-10-26 19:45:06 UTC
(In reply to comment #101)
> (In reply to comment #100)
> > well, i am stuck now.
> > 
> > after the second, so not the first one, the one with mutter 1.8.2, update, i am
> > not able to reproduce the bug. first i had the big leak, then after the update
> > to mutter 1.8.2, it went slower and less critical, but there was an update in
> > between, and i am now on 70 MB of RAM for gnome-shell for a long time now.
> > 
> > it's getting hard to find the remeaning leaks now.
> 
> So which update fixed it for you?

i dont know, first of all, this mutter 1.8.2 was very important update, and then there were so many packages ... i dont know what everything came in. i am running now the current Fedora 16 w/o updates-testing.
Comment 103 Zdeněk Janák 2011-11-13 13:14:06 UTC
No more memory leak and high CPU usage after disabling GPaste gnome-shell extension on up to date ArchLinux with Gnome 3.2.1.
Comment 104 Benjamín Valero Espinosa 2011-11-13 13:26:06 UTC
After using Fedora 16 some days (with Gnome 3.2), I have not been able to reproduce the leaks I saw in Fedora 15 (Gnome 3.0), specially when using Java applications. That's not to say this bug is fixed, but at least it seems so for me.
Comment 105 Ulukai 2011-11-15 11:36:08 UTC
Up to date Arch with system monitor extension (bottom left) gives me still memory leaks up to 600 MB. When I disable the extension Gnome-Shell stays under 100 MB... 

Could it be the extension?
Comment 106 Peter Robinson 2011-11-15 11:39:53 UTC
(In reply to comment #105)
> Up to date Arch with system monitor extension (bottom left) gives me still
> memory leaks up to 600 MB. When I disable the extension Gnome-Shell stays under
> 100 MB... 
> 
> Could it be the extension?

Yes, so you'll need to report that to the extension(s) at fault.
Comment 107 Ulukai 2011-11-16 10:34:06 UTC
(In reply to comment #104)
> After using Fedora 16 some days (with Gnome 3.2), I have not been able to
> reproduce the leaks I saw in Fedora 15 (Gnome 3.0), specially when using Java
> applications. That's not to say this bug is fixed, but at least it seems so for
> me.

Were you using any extensions at all?
Comment 108 Benjamín Valero Espinosa 2011-11-16 10:43:06 UTC
(In reply to comment #107)
> (In reply to comment #104)
> > After using Fedora 16 some days (with Gnome 3.2), I have not been able to
> > reproduce the leaks I saw in Fedora 15 (Gnome 3.0), specially when using Java
> > applications. That's not to say this bug is fixed, but at least it seems so for
> > me.
> 
> Were you using any extensions at all?

Yes, some of them. I am using cpu-temperature, alternative-status-menu and remove-accesibility-icon. Last night I had JDownloader (Java app) running for several hours and I couldn't notice any leak in gnome-shell, when in Fedora 15 the leak was about 50 MB/hour.
Comment 109 Benjamín Valero Espinosa 2011-11-16 11:52:39 UTC
(In reply to comment #105)
> Up to date Arch with system monitor extension (bottom left) gives me still
> memory leaks up to 600 MB. When I disable the extension Gnome-Shell stays under
> 100 MB... 
> 
> Could it be the extension?

I have tried to enable the System Monitor extension (Fedora 16, Gnome 3.2) and the memory has increased 100 MB in half an hour, so perhaps is problem of the extension itself :(
Comment 110 Ulukai 2011-11-17 20:10:19 UTC
(In reply to comment #97)
> (In reply to comment #95)
> > That aside, the memory leak bug is REALLY annoying. I'm checking Arch repos for
> > new packages every day to get it out of my system... :-(
> 
> https://live.gnome.org/ThreePointThree
> 
> 3.2.2 is happening on November 16th.

November 17th today and no new Gnome-Shell release. Is a 3.2.2 release still planned?
Comment 111 André Klapper 2011-11-17 20:14:08 UTC
(In reply to comment #110)
> > 3.2.2 is happening on November 16th.
> 
> November 17th today and no new Gnome-Shell release. Is a 3.2.2 release still
> planned?

Yes, "as soon as it's done". But that's off-topic for this report... :)
Comment 112 Ulukai 2011-11-17 20:16:19 UTC
Yes and no: it may be the system monitor extension, but there were other memory leaks plugged as well thanks to our logs. So I'm still hoping that the memory usage will drop with 3.2.2 :) 

Thanks for answering.
Comment 113 T.J.Pinkert 2012-01-04 12:52:11 UTC
Created attachment 204563 [details]
valgrind memcheck and massif outputs

running gnome-shell package 3.0.2-8+b1 from the Debian testing repository. There are still very slow rate memory leaks in this version. I hope these will still contribute to the devellopers.
Comment 114 Milan Bouchet-Valat 2012-01-04 13:35:05 UTC
This seems to indicate something wrong in the Intel i915 driver. Could you install debugging symbols for this lib (libgl1-mesa-dri-dbg), re-run the Valgrind memcheck, and report this to the upstream developers on https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa

Please include the output of lspci -vnn there, and the version of libgl1-mesa-dri you're using.

==5694== Invalid read of size 4
==5694==    at 0x77A161A: ??? (in /usr/lib/i386-linux-gnu/dri/i915_dri.so)
==5694==    by 0x7780A2F: ??? (in /usr/lib/i386-linux-gnu/dri/i915_dri.so)
==5694==    by 0x775608B: ??? (in /usr/lib/i386-linux-gnu/dri/i915_dri.so)
==5694==    by 0x77304E6: ??? (in /usr/lib/i386-linux-gnu/dri/i915_dri.so)
==5694==    by 0x4B8D21C: ??? (in /usr/lib/i386-linux-gnu/libGL.so.1.2)
==5694==    by 0x4B66FC6: glXMakeContextCurrent (in /usr/lib/i386-linux-gnu/libGL.so.1.2)
==5694==    by 0x4C177C6: ??? (in /usr/lib/i386-linux-gnu/libcogl.so.5.0.1)
==5694==    by 0x4BDA2A3: cogl_display_setup_EXP (in /usr/lib/i386-linux-gnu/libcogl.so.5.0.1)
==5694==    by 0x4BD95FD: cogl_renderer_check_onscreen_template_EXP (in /usr/lib/i386-linux-gnu/libcogl.so.5.0.1)
==5694==    by 0x4A4081A: ??? (in /usr/lib/i386-linux-gnu/libclutter-glx-1.0.so.0.800.2)
==5694==    by 0x4A62CE1: ??? (in /usr/lib/i386-linux-gnu/libclutter-glx-1.0.so.0.800.2)
==5694==    by 0x4A822D8: ??? (in /usr/lib/i386-linux-gnu/libclutter-glx-1.0.so.0.800.2)
Comment 115 Jasper St. Pierre (not reading bugmail) 2012-01-04 14:21:47 UTC
(In reply to comment #113)
> Created an attachment (id=204563) [details]
> valgrind memcheck and massif outputs
> 
> running gnome-shell package 3.0.2-8+b1 from the Debian testing repository.
> There are still very slow rate memory leaks in this version. I hope these will
> still contribute to the devellopers.

gnome-shell 3.0.2 is almost a year old. We've fixed a significant number of memory leaks since then.

(In reply to comment #114)
> This seems to indicate something wrong in the Intel i915 driver. Could you
> install debugging symbols for this lib (libgl1-mesa-dri-dbg), re-run the
> Valgrind memcheck, and report this to the upstream developers on
> https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa

Not really. In order to make GL go fast, drivers have to play all sorts of tricks, including doing things that valgrind doesn't quite understand.
Comment 116 graysky 2012-01-07 20:00:57 UTC
Just for shits and giggles, I installed a fresh Arch linux x86_64 + gnome to a spare partition and booted into it leaving it sit logged in and measuring mem usage of gnomeshell using the attached script.  It still leaks over time and the magnititude of the leak has gotten worse by 10x :(

old (post 37) leak is ~0.0357 MB/min
fresh install leak is ~0.254 MB/min

Graph: http://s8.postimage.org/e7uqm63rp/new.png

Arch packages are up-to-date:

extra/gnome-shell 3.2.1-1 (gnome)
extra/mutter 3.2.1-1 (gnome)

Thoughts from others?

Script:
#!/bin/bash
for i in {1..6000}; do
  number=$(ps -A --sort -rss -o comm,rss | head -n 3 | grep gnome-shell | awk '{ print $2 }')
  correct=$(echo "scale=2;$number/1024" | bc)
  echo "$correct $i" >> /tmp/mem_usage.txt 
  sleep 60s
done
Comment 117 graysky 2012-01-08 12:59:26 UTC
Here is a more complete (and linear) data set acquired on my laptop.  Here I just logged into gnome and left it sit for 10 h.

http://s18.postimage.org/rjb4g47uh/laptop.png

Here there is no real difference between old and new:

old (post 37) leak is ~0.0357 MB/min
fresh install leak is ~0.0495 MB/min
Comment 118 André Klapper 2012-02-03 13:38:02 UTC
Bumping version as per comments 116 and 117
Comment 119 Jasper St. Pierre (not reading bugmail) 2012-02-03 14:56:13 UTC
Felipe, can you try again with GNOME Shell 3.2.2.1? There have been a number of memory leak fixes in that release.
Comment 120 Felipe Lessa 2012-02-03 15:06:45 UTC
$ pacman -Qi gnome-shell | grep Ver
Versão               : 3.2.2.1-1
$ ps axu --sort=rss | tail -n 1
felipe     946  7.8  8.2 2959808 1354728 ?     Sl   Jan30 412:12 /usr/bin/gnome-shell

So it's 1.3 GiB of RSS for gnome-shell =(.
Comment 121 Peter Robinson 2012-02-03 15:12:48 UTC
(In reply to comment #120)
> $ pacman -Qi gnome-shell | grep Ver
> Versão               : 3.2.2.1-1
> $ ps axu --sort=rss | tail -n 1
> felipe     946  7.8  8.2 2959808 1354728 ?     Sl   Jan30 412:12
> /usr/bin/gnome-shell
> 
> So it's 1.3 GiB of RSS for gnome-shell =(.

What extensions do you have enabled? Most of the recent gnome-shell 3.2 releases without extensions have been pretty good with leaking. extensions are another matter entirely. I would try disabling all your extensions and see if the problem still exists, if not re-enable them one by one to work out the culprit.
Comment 122 Felipe Lessa 2012-02-03 16:13:22 UTC
There's only one extension, the gnome-system-monitor-applet.  It's very useful to me but I guess I can live without it for some time.  Do you think that it's possible for the leak to be there?
Comment 123 Milan Bouchet-Valat 2012-02-03 16:17:43 UTC
(In reply to comment #122)
> There's only one extension, the gnome-system-monitor-applet.  It's very useful
> to me but I guess I can live without it for some time.  Do you think that it's
> possible for the leak to be there?
Yes, likely. It's easy to check, anyway.

Anybody here experiencing leaks when all extensions are disabled?
Comment 124 Owen Taylor 2012-02-03 16:49:54 UTC
(In reply to comment #122)
> There's only one extension, the gnome-system-monitor-applet.  It's very useful
> to me but I guess I can live without it for some time.  Do you think that it's
> possible for the leak to be there?

See comment 105 for someone who was having a memory leak specifically associated with that extension. (I think - there are two system monitor extensions around.)
Comment 125 Felipe Lessa 2012-02-05 01:43:12 UTC
Still seems to be leaking memory.  It's been running for ~38 hours, and its RSS went from ~200 MiB to ~325 MiB.
Comment 126 Milan Bouchet-Valat 2012-02-05 11:54:42 UTC
(In reply to comment #125)
> Still seems to be leaking memory.  It's been running for ~38 hours, and its RSS
> went from ~200 MiB to ~325 MiB.
Without any extensions enabled?
Comment 127 Felipe Lessa 2012-02-05 13:43:25 UTC
Yes, that's right, no extensions at all.  It's now on ~337 MiB.
Comment 128 Chad Rodrigue 2012-02-17 21:51:34 UTC
Hi.  I'm running Ubuntu 11.10, and using the testing repositories to run Gnome-Shell 3.3.5 on a Thinkpad W510.

I'm using a handful of the extensions packaged with the product.  As long as I DO NOT USE the "System Monitor" extension, I'm happy to report that the leak(s) appear to be fixed: G-S starts with 85M of RAM, and in short order expands to ~110-130, where it stays indefinitely.  (How much or how little depends on how many windows and desktops I have open).

If I DO use the System Monitor extension, however, the leak persists at a rate of about a meg every minute or three.
Comment 129 Chad Rodrigue 2012-02-18 16:57:56 UTC
Update: I left this computer on all night (18 hours), with no apps running and the screen locked.

I checked in on it at around midnight: 172M.

I checked in on it just now: 155M.  

I opened this browser to fill out this comment: 139M.
Comment 130 darkxst 2012-02-19 01:25:16 UTC
I am still experience leaks with all extensions disabled under gnome-shell 3.2.2.1 on Ubuntu (11.10). typically 300MB after 24 hours, 5-600
after a few days.
Comment 131 Chad Rodrigue 2012-02-19 02:15:12 UTC
I experienced leaks with 3.2.2.1 as well.
Comment 132 André Klapper 2012-02-19 09:10:47 UTC
In order to help, please avoid generic "I see this too" comments.
Please make sure that you have disabled any extensions and clearly state this when commenting, plus provide exact version info and distribution name. Thanks!
Comment 133 nikita.vetoshkin 2012-02-21 10:21:54 UTC
I have the same issue with gnome-shell-3.2.2.1-1.fc16.x86_64 with standard shell theme and no extensions with faenza icon set. Restarting with Alt+F2 and 'r' drops memory usage to normal. How can I help? Can someone write a list of actions one need to perform to provide enough info?
Comment 134 Chad Rodrigue 2012-02-26 07:05:08 UTC
I spoke too soon.  

I am now running Gnome-Shell 3.3.90, no extensions, and the leak has returned (if it ever went away).  

In fact, there actually appear to be two leaks - one is a very slow yet constant leak that requires no activity to trigger, and the other appears to have something to do with images.  

The first is easy to trigger: I start a Gnome-Shell session, hit Alt+F2, launch the System Monitor application, and then leave it for a while.  I do not go to Activities, or do anything else.  

I did this at 7PM: G-S was using 92MB.  I came back to the computer at 12:30PM: G-S was using 161MB. 

The second leak - which appears to be related to images - is visible when I use music players *with the album cover plugins on*.  Both Banshee and Rhythmbox both display this issue.  The memory seems to increase by the same amount as each newly-displayed album cover is in size: most of my album covers are 500k, and every time a previously-unseen album cover appears, Gnome-Shell's memory allocation increases by ~500k.  Closing the music app does not return the memory; only a shell restart does.  Displaying the same cover does not cause an increase.

As this is the case, and as the system monitor extensions (both of them) use images to display their data, and cause a linear rise in memory usage if enabled, I'm strongly beginning to suspect that Gnome-Shell caches images in memory but never lets them go.  This is also noticeable immediately by going into the Activities -> Applications area: once I do that, and the icons are loaded and displayed, Gnome-Shell takes up an additional few megs of RAM (actual amount depends on how many icons I have in that menu; more icons, more memory).  This memory is also never released.

I don't need to test the first leak - just hang out and it happens.  I don't know how to test for the second one, though... should I just do the valgrind thing?  Do I need to supply more data at all, or do we have enough?  How can I help?
Comment 135 Jasper St. Pierre (not reading bugmail) 2012-02-26 07:23:21 UTC
(In reply to comment #134)
> I'm strongly beginning to suspect that Gnome-Shell caches images in
> memory but never lets them go.

We often do to help with performance issues on subsequent visits to the overview.

(In reply to comment #134)
> The second leak - which appears to be related to images - is visible when I use
> music players *with the album cover plugins on*.  Both Banshee and Rhythmbox
> both display this issue.  The memory seems to increase by the same amount as
> each newly-displayed album cover is in size: most of my album covers are 500k,
> and every time a previously-unseen album cover appears, Gnome-Shell's memory
> allocation increases by ~500k.  Closing the music app does not return the
> memory; only a shell restart does.  Displaying the same cover does not cause an
> increase.

Do you have notifications with album art in them?
Comment 136 Chad Rodrigue 2012-02-26 07:54:14 UTC
> We often do to help with performance issues on subsequent visits to the
overview.

Well, that certainly explains why the system monitors steadily chomp memory.

> Do you have notifications with album art in them?

I do not... in fact, I turn off notifications entirely in the music players.  I can hear when the song changes, and know most of the songs, so I don't need the visual clutter.
Comment 137 Olav Vitters 2012-02-26 11:53:12 UTC
Seeins also high memory usage with 3.3.90 (growing to 1.3GB within 12 hours or so). Doing nothing special and no extensions installed.

I think due to the almost OOM state; my gnome-settings-daemon has crashed. I haven't logged out&in yet to fix that. Could also be that gnome-settings-daemon has issues and this is causing gnome-shell to balloon in size.
Comment 138 Chad Rodrigue 2012-02-28 04:02:51 UTC
Just earlier this evening, the Testing repository updated Gnome-Shell to 3.3.90+git20120227.fad0b96f-0ubuntu1~11.10~ricotz0.  Some other bits of G-S were updated as well.  This is not unusual.

What *is* unusual is that BOTH leaks I reported seem to be mostly fixed on this version.  I, so far, can only get G-S to go above ~98MB of RAM by opening up new applications, and when I close them, the memory gets freed.  

Both Banshee and RB no longer continue to grow the memory usage, either, cover art or no.  

I've more testing to do to confirm this, but earlier today my usage hit 500M after about 3 hours, and I've been running this new version for as long and it seems to be stationary at 98M still (provided I close all apps but the browser and the system monitor).  

Bottom line: if you guys did something in the interim, its working.  :-)
Comment 139 Jasper St. Pierre (not reading bugmail) 2012-02-28 04:27:28 UTC
(In reply to comment #137)
> Seeins also high memory usage with 3.3.90 (growing to 1.3GB within 12 hours or
> so). Doing nothing special and no extensions installed.

This is entirely my fault. http://git.gnome.org/browse/gnome-shell/commit/?id=d2aab9d6a620f561e71a884ff5c44ec0bb654f9a should fix it.

(In reply to comment #138)
> Just earlier this evening, the Testing repository updated Gnome-Shell to
> 3.3.90+git20120227.fad0b96f-0ubuntu1~11.10~ricotz0.  Some other bits of G-S
> were updated as well.  This is not unusual.
> 
> What *is* unusual is that BOTH leaks I reported seem to be mostly fixed on this
> version.  I, so far, can only get G-S to go above ~98MB of RAM by opening up
> new applications, and when I close them, the memory gets freed.  
> 
> Both Banshee and RB no longer continue to grow the memory usage, either, cover
> art or no.  

It was probably the removal of the Recent Items search provider, then.
Comment 140 Xavier Claessens 2012-03-21 11:08:13 UTC
For info, I was watching a movie in totem (3.3.90) last night, and when leaving the fullscreen at the end, the laptop was not responding for a few minutes. Turned out gnome-shell process had slowly filled the whole swap during the playback. It seems related to video playback, and it seems HD videos are worse. "ALT-F2 r" freed the whole swap and ram.
Comment 141 Xavier Claessens 2012-03-21 11:12:35 UTC
Probably should have told, it's a lenovo x200s laptop, intel GM45 Express Chipset.
Comment 142 Eduardo 2012-08-23 15:27:45 UTC
I can confirm that, under GS 3.4.2 on Fedora 17 there is a memory leak when using System-Monitor Extension (extensions.gnome.org/extension/120/system-monitor/). Once uninstalled, I noticed no more leaks.
Comment 143 Anthony Ruhier 2012-11-12 09:52:53 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.

Arch Linux
Gnome 3.6.1
Comment 144 christian.gredig 2013-03-09 03:17:57 UTC
I can confirm what Anthony said. By clicking one of the top bar icons and then hovering over the others again and again I can multiply the memory use in seconds. It took me less than a minute to increase it from 50MB to almost 200MB. Some elements increase the memory usage more, some less. Looks like Gnome keeps a new copy every time I hover one of them.

Ubuntu Gnome Remix 12.10
Gnome Shell 3.6.2
Comment 145 Jasper St. Pierre (not reading bugmail) 2013-03-09 03:27:57 UTC
The used memory should go away when you do a full GC: try opening the looking glass with Alt+F2 "lg", and then click "Full GC" on the memory tab.

This is partially a SpiderMonkey bug. If all the dates align just right, we may be able to fix this for 3.8.
Comment 146 christian.gredig 2013-03-18 03:08:15 UTC
(In reply to comment #145)
> The used memory should go away when you do a full GC: try opening the looking
> glass with Alt+F2 "lg", and then click "Full GC" on the memory tab.
> 
> This is partially a SpiderMonkey bug. If all the dates align just right, we may
> be able to fix this for 3.8.

Nope, it does not go away when I do a full GC. Even worse, the looking glass stays open somehow and increases the memory used by Gnome by 30MB. I then restarted Gnome Shell (with "r"). Directly after the restart it was at 37MB memory usage, now while writing this comment it's at 67MB.
Comment 147 Jasper St. Pierre (not reading bugmail) 2013-03-18 03:28:19 UTC
There's still some issues with full GC and optimizations and conservative stack scanning not working 100%. This is why SpiderMonkey is moving to an exact-rooted GC.
Comment 148 Stéphane Démurget 2013-03-18 08:26:21 UTC
(In reply to comment #144)
> I can confirm what Anthony said. By clicking one of the top bar icons and then
> hovering over the others again and again I can multiply the memory use in
> seconds. It took me less than a minute to increase it from 50MB to almost
> 200MB. Some elements increase the memory usage more, some less. Looks like
> Gnome keeps a new copy every time I hover one of them.
> 
> Ubuntu Gnome Remix 12.10
> Gnome Shell 3.6.2

This is definitely the cairo context leak that was fixed in 3.7.4.
(It was not backported if I'm not mistaken?)

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

Short version: by playing some time with the popups you'd go up to 500MB+ or even 1GB+ after a long session; after the patch it peeks to 250MB, which shows there's still room for improvements, but at least it's not leaking. I had the patch enabled for about 3 weeks with no restart and memory always stayed around 250MB.

Could you try confirming this with a test version maybe? That would be great.

There's a test ISO of 3.7.90 beta at: http://ftp.acc.umu.se/pub/GNOME/misc/testing/GNOME-3.7.90.iso
Comment 149 darkxst 2013-03-18 08:38:45 UTC
From my observations Without re-enabling GC on idle, spidermonkey seems to loose track of things that should be GC'ed. So really the cario fix does little to help.

Re-enabling GC on idle brings memory usage well back inline with expectations, but is only possible with the new mozjs17. Otherwise you will get constant GC deadlocks.

There should be a mozjs17 branch of gjs coming (wip here, https://bugzilla.gnome.org/show_bug.cgi?id=690982#c76), but it will be optional and as yet no distro has picked up forthcoming mozjs17 as far as I know.
Comment 150 Jiehan Zheng 2013-07-11 01:50:43 UTC
Still happens in GNOME Shell 3.8.3.  After hours since my last Alt-F2, it went up to 800MB again.  I saw it went up to 1.5 GB earlier today and caused OOM killer to function.
Comment 151 darkxst 2013-07-11 02:41:04 UTC
Jiehan, what version of spidermonkey are you using? 
Many distros are still using the old version, where as this is fixed when using mozjs17.
Comment 152 Jiehan Zheng 2013-07-11 03:10:42 UTC
Hi darkxst-- my laptop is running Arch Linux and all the packages are up-to-date.  Arch Linux uses rolling release, so I believe spidermonkey is up-to-date as well.  This is my first time hearing about spidermonkey...how exactly can I check its version?  Thanks!

The problem seems worse on my system.  Whenever the Activities screen shows up, memory usage goes up by 40+ MB.
Comment 153 darkxst 2013-07-11 03:25:11 UTC
check for a package called mozjs or js.
Comment 154 Jiehan Zheng 2013-07-11 03:27:02 UTC
I have js 17.0.0 installed.
Comment 155 darkxst 2013-07-11 05:24:41 UTC
Possibly Arch needs to re-enable periodic GC then.
Comment 156 Matthew Wardrop 2013-09-25 22:01:49 UTC
I'm still experiencing this on Arch Linux with Gnome Shell 3.10.0.1 . After using it for no more than an hour, my memory usage is already at about 650 MB. :(. Is there a solution for this? I need that memory for other things.
Comment 157 Anthony Ruhier 2013-09-25 22:38:06 UTC
Same thing for me on ArchLinux with gnome 3.10 installed through de gnome-unstable repo, and the memory consumption increases with the usage like it did with Gnome 3.8.

@darkxst : Do you know if it's enabled in other distros ? And do you know why they would have disabled the periodic GC in the js package in Arch ?
Comment 158 Anthony Ruhier 2013-09-25 22:46:41 UTC
@darkxst: and by periodic GC, you mean the option "--enable-gcgenerational" for the configure file of js ?
Comment 159 Jan Alexander Steffens (heftig) 2013-09-26 08:20:43 UTC
Arch uses the same configure flags to js17 as Fedora does, with the addition of --with-system-ffi.
Comment 160 darkxst 2013-09-26 08:37:48 UTC
Try reverting this patch and see if it helps:
https://git.gnome.org/browse/gnome-shell/commit/?id=6f605598de1eb4361ef912e85edb27a8b7b96b21
Comment 161 Anthony Ruhier 2013-09-26 15:34:07 UTC
It seems to be much better in reverting this commit.

It isn't more laggy than before, and the memory consumption is more stable and lower (< 150mo, before it was more like 500mo after a few hours).
I will test it during a few days and tell you if it's stable and really better.
Comment 162 Anthony Ruhier 2013-09-27 07:35:16 UTC
In fact the leak is still there. It seems to be a bit better, but it doesn't fix it. It starts at 115mo consumed, that is great, but grows with usage to 400 - 500mo with only a few extensions enabled.

Is there a way to set the GC to be more aggressive ?
Comment 163 Anthony Ruhier 2013-09-29 17:08:57 UTC
Bug report related : https://bugzilla.gnome.org/show_bug.cgi?id=642652
Comment 164 Anthony Ruhier 2013-09-30 07:32:33 UTC
Edit : My bad, correct link : https://bugzilla.gnome.org/show_bug.cgi?id=685513
Comment 165 Kevin 2013-10-17 11:14:58 UTC
I can readily reproduce this with Fedora 19 and gnome-shell 3.8.4.2.fc19.  All I have to do is log in and use the super key a few times while watching top on a terminal and the RES memory drives up.  I've disabled all extensions and removed most of them.  I also did a pmap on gnome-shell while just after doing alt-f2 r and when I saw it around 4G of RES.  

Here is the diff:

diff /var/tmp/gnome-shell-pmap-311MB /var/tmp/gnome-shell-pmap-4G 
6c6
< 00000000010dd000   67488 rw--- 0000000000000000 000:00000   [ anon ]
---
> 00000000010dd000  158332 rw--- 0000000000000000 000:00000   [ anon ]
652,662c652,689
< 00007f5a80000000     424 rw--- 0000000000000000 000:00000   [ anon ]
< 00007f5a8006a000   65112 ----- 0000000000000000 000:00000   [ anon ]
< 00007f5a88000000     228 rw--- 0000000000000000 000:00000   [ anon ]
< 00007f5a88039000   65308 ----- 0000000000000000 000:00000   [ anon ]
< 00007f5a8c000000     208 rw--- 0000000000000000 000:00000   [ anon ]
< 00007f5a8c034000   65328 ----- 0000000000000000 000:00000   [ anon ]
< 00007f5a90000000     136 rw--- 0000000000000000 000:00000   [ anon ]
< 00007f5a90022000   65400 ----- 0000000000000000 000:00000   [ anon ]
< 00007f5a95196000   47528 rw--- 0000000000000000 000:00000   [ anon ]
< 00007f5a98000000     232 rw--- 0000000000000000 000:00000   [ anon ]
< 00007f5a9803a000   65304 ----- 0000000000000000 000:00000   [ anon ]
---
> 00007f594b88a000  415880 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f59656ac000  415880 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f597f0ce000  748584 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f59ace00000    1024 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f59ad3d8000 2994336 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a64000000     136 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a64022000   65400 ----- 0000000000000000 000:00000   [ anon ]
> 00007f5a69196000   47528 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a6c000000     476 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a6c077000   65060 ----- 0000000000000000 000:00000   [ anon ]
> 00007f5a70052000    4096 rw-s- 0000000046796000 000:00005 nvidia0
> 00007f5a70452000    4096 rw-s- 000000011182d000 000:00005 nvidia0
> 00007f5a70b00000    1024 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a70c52000  249528 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a80000000     752 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a800bc000   64784 ----- 0000000000000000 000:00000   [ anon ]
> 00007f5a84000000    4096 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a84400000    4096 rw-s- 0000000047529000 000:00005 nvidia0
> 00007f5a84800000    2048 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a84a00000    3072 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a84d00000    5120 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a85200000    3072 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a8552f000       4 ----- 0000000000000000 000:00000   [ anon ]
> 00007f5a85530000   43840 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a88000000     512 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a88080000   65024 ----- 0000000000000000 000:00000   [ anon ]
> 00007f5a8c000000     268 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a8c043000   65268 ----- 0000000000000000 000:00000   [ anon ]
> 00007f5a90000000     576 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a90090000   64960 ----- 0000000000000000 000:00000   [ anon ]
> 00007f5a94000000    3072 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a94300000    4096 rw-s- 00000000accf6000 000:00005 nvidia0
> 00007f5a94700000    2048 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a94995000       4 ----- 0000000000000000 000:00000   [ anon ]
> 00007f5a94996000   55720 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a98000000     380 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a9805f000   65156 ----- 0000000000000000 000:00000   [ anon ]
> 00007f5a9c000000    2048 rw--- 0000000000000000 000:00000   [ anon ]
667,672c694,699
< 00007f5a9cc8d000       4 ----- 0000000000000000 000:00000   [ anon ]
< 00007f5a9cc8e000    8192 rw--- 0000000000000000 000:00000   [ anon ]
< 00007f5a9d48e000       4 ----- 0000000000000000 000:00000   [ anon ]
< 00007f5a9d48f000    8192 rw--- 0000000000000000 000:00000   [ anon ]
< 00007f5a9e490000    4096 rw-s- 00000001aceff000 000:00005 nvidia0
< 00007f5a9e890000    4096 rw-s- 000000022fbf6000 000:00005 nvidia0
---
> 00007f5a9cd00000    4096 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a9d100000    8192 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a9d900000    4096 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a9dd00000    8192 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a9e500000    3072 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5a9e800000    4096 rw--- 0000000000000000 000:00000   [ anon ]
722c749
< 00007f5aa718f000    4096 rw-s- 00000001e0d3d000 000:00005 nvidia0
---
> 00007f5aa718f000    4096 rw-s- 00000001fde25000 000:00005 nvidia0
725c752
< 00007f5aa7a8f000    2048 rw-s- 00000001689ea000 000:00005 nvidia0
---
> 00007f5aa7b00000    1024 rw--- 0000000000000000 000:00000   [ anon ]
737c764,765
< 00007f5ab2600000    3072 rw--- 0000000000000000 000:00000   [ anon ]
---
> 00007f5ab2400000    5120 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5ab29a1000     356 r---- 0000000000000000 0fd:00002 DejaVuSerif.ttf
742a771,773
> 00007f5ab2e28000       4 r---- 0000000000000000 0fd:0000c gschemas.compiled
> 00007f5ab2e29000       4 r---- 0000000000000000 0fd:0000c gschemas.compiled
> 00007f5ab2e2a000       4 r---- 0000000000000000 0fd:0000c gschemas.compiled
744a776
> 00007f5ab2e2d000       4 r---- 0000000000000000 0fd:0000c gschemas.compiled
826,831c858,863
< 00007f5ab8000000     132 rw--- 0000000000000000 000:00000   [ anon ]
< 00007f5ab8021000   65404 ----- 0000000000000000 000:00000   [ anon ]
< 00007f5abc000000     132 rw--- 0000000000000000 000:00000   [ anon ]
< 00007f5abc021000   65404 ----- 0000000000000000 000:00000   [ anon ]
< 00007f5ac0000000    3968 rw--- 0000000000000000 000:00000   [ anon ]
< 00007f5ac03e0000   61568 ----- 0000000000000000 000:00000   [ anon ]
---
> 00007f5ab8000000    1076 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5ab810d000   64460 ----- 0000000000000000 000:00000   [ anon ]
> 00007f5abc000000     492 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5abc07b000   65044 ----- 0000000000000000 000:00000   [ anon ]
> 00007f5ac0000000    5724 rw--- 0000000000000000 000:00000   [ anon ]
> 00007f5ac0597000   59812 ----- 0000000000000000 000:00000   [ anon ]
853c885,886
< 00007f5ac5346000      36 r---- 0000000000000000 0fd:0000c user (deleted)
---
> 00007f5ac534e000       4 r---- 0000000000000000 0fd:0000c gschemas.compiled
> 00007f5ac534f000       4 r---- 0000000000000000 0fd:0000c gschemas.compiled
898a932,935
> 00007f5ac7572000       4 r---- 0000000000000000 0fd:0000c gschemas.compiled
> 00007f5ac7573000       4 r---- 0000000000000000 0fd:0000c gschemas.compiled
> 00007f5ac7574000       4 r---- 0000000000000000 0fd:0000c gschemas.compiled
> 00007f5ac7575000       4 r---- 0000000000000000 0fd:0000c gschemas.compiled
930c967
< mapped: 1644988K    writeable/private: 250444K    shared: 165972K
---
> mapped: 6842232K    writeable/private: 5315044K    shared: 172116K
Comment 166 Chad Rodrigue 2014-09-29 17:31:14 UTC
This is *still* a problem in Gnome-Shell 3.14.  It affects every driver on every system I've ever tried in on, ever.  

It would so make my life if this could be fixed.
Comment 167 André Klapper 2014-09-29 18:55:45 UTC
Chad: Please file a separate report with specific test information. 
Also see previous comments in this report.
Comment 168 jeremy9856 2015-11-24 09:59:37 UTC
There is at least 3 bugs reports for the high memory usage of Gnome-shell.
This one, #735705 and #701230. I comment on the 3, choose the one you want to work on it.

I just installed Fedora 23 with Nvidia proprietary drivers and a 5 minutes after Gnome shell consume 450MB !

Maybe it's time to fix this ?
Comment 169 Milan Bouchet-Valat 2015-11-24 11:26:15 UTC
jeremy9856: Please read what André said and open a new report. There's no reason this should be the same issue. In particular, try with the open source driver and report whether this makes a difference.
Comment 170 Hussam Al-Tayeb 2015-11-24 11:54:22 UTC
I find reverting https://git.gnome.org/browse/gnome-shell/commit/src/shell-global.c?id=6f605598de1eb4361ef912e85edb27a8b7b96b21 slows down memory increase but this code was apparently causing deadlocks.
Comment 171 jeremy9856 2015-11-24 13:14:41 UTC
(In reply to Milan Bouchet-Valat from comment #169)
> jeremy9856: Please read what André said and open a new report. There's no
> reason this should be the same issue. In particular, try with the open
> source driver and report whether this makes a difference.
Ok this one is for Mutter and for me it's the gnome-shell process that use far too much memory. But the 2 others, bug 735705 and bug 701230, already describe the problem so I don't think I need to open an other bug report.
Comment 172 jeremy9856 2015-11-24 18:01:34 UTC
(In reply to Milan Bouchet-Valat from comment #169)
> jeremy9856: In particular, try with the open
> source driver and report whether this makes a difference.
It happen with the open source driver too but less. Gnome-shell (Fedora 23, Gnome 3.18) start at 50MB and after an hour it's at 180MB... Note that on Fedora 22 with Gnome 3.16 with the open source driver Gnome-shell doesn't go beyond 120MB I think.

So I confirm that, on Gnome 3.18, there is some kind of memory leak with the open source Nouveau drivers and there is some kind of HUGE memory leak with the closed source Nvidia drivers.
Comment 173 Chad Rodrigue 2015-11-24 19:43:26 UTC
It's a leak in _all_ Xorg drivers.  I have personally tested it with Nouveau, nVidia, Intel, VESA, and whatever Virtualbox uses.  I have also replicated the problem on any given set of hardware available -- I have literally not seen a machine running Gnome-Shell that doesn't do this.  

Its the same leak.  It affects all drivers.  The only real difference is that different drivers use different amounts of memory -- the nVidia binary uses about twice as much memory as open source drivers in general, for pretty much everything.  (The nVidia devs tell me this is because nVidia caches a lot more things for speed purposes in comparison, and it's these caches that are being leaked... or, more accurately, not freed, for whatever reason).  

But since it _looks like_ it's only happening to nVidia because the leak is more visible and in greater amounts on that driver, that's traditionally where blame has been placed.
Comment 174 Hussam Al-Tayeb 2015-11-24 20:07:43 UTC
Out of interest, are people running gnome-shell on wayland also seeing issues?
Comment 175 Dams 2016-08-22 09:12:51 UTC
Definitely still leaking. Using wayland on fedora 24.
Comment 176 André Klapper 2016-08-22 10:06:43 UTC
Valgrind logs welcome.
Comment 177 Christian Stadelmann 2016-09-21 20:25:05 UTC
Created attachment 336030 [details]
valgrind logs

Still leaking for me too. I don't know a way to reproduce.

I managed to get gnome-shell running under valgrind, so I'm attaching a log. Note that this is for the X11 session only since running `--replace` doesn't work on wayland due to architectural changes (see https://bugzilla.gnome.org/show_bug.cgi?id=741665).

Steps to reproduce:
1. log in into a gnome+X11 session
2. run the script below from a tty
3. try to use the gnome-shell session
4. from another tty, run the second script

First script:

#!/usr/bin/bash
gnome_session=$(pgrep -u $USER gnome-session)
eval export $(sed 's/\o000/\n/g;' < /proc/$gnome_session/environ | grep DISPLAY)
eval export $(sed 's/\o000/\n/g;' < /proc/$gnome_session/environ | grep XAUTHORITY)
eval export $(sed 's/\o000/\n/g;' < /proc/$gnome_session/environ | grep DBUS_SESSION_BUS_ADDRESS)
export G_SLICE=always-malloc
export G_DEBUG=gc-friendly
valgrind --leak-check=full --track-origins=yes /usr/bin/gnome-shell --replace |& tee gnome-shell-valgrind.log


Second script:

#!/usr/bin/bash
gnome_session=$(pgrep -u $USER gnome-session)
eval export $(sed 's/\o000/\n/g;' < /proc/$gnome_session/environ | grep DISPLAY)
eval export $(sed 's/\o000/\n/g;' < /proc/$gnome_session/environ | grep XAUTHORITY)
eval export $(sed 's/\o000/\n/g;' < /proc/$gnome_session/environ | grep DBUS_SESSION_BUS_ADDRESS)
/usr/bin/gnome-shell --replace


Still, under valgrind gnome-shell is so horribly slow, it doesn't look like it will ever react to any keyboard or mouse input. Even with animations disabled. Therefore, I couldn't use gnome-shell as I would in a regular session.
Comment 178 Jean-François Fortin Tam 2016-12-14 05:05:01 UTC
Created attachment 341930 [details]
sysprof output with GNOME 3.22

To be clear, from what we've seen here combined with the experience we've had over the years with this, and by progressively eliminating external factors, it is looking increasingly certain that nothing in the stack, aside of gnome-shell itself, is the problem. If someone proves me wrong and the culprit is actually somewhere lower in the graphics stack (kernel/drivers/mesa/clutter/cairo/DRI/etc.), well, I'll buy that person a Ferrari.

After all, over the past years, I've seen this happen only with GNOME Shell, on every GNOME Shell version released and unreleased since 2010, on every driver and hardware, on X and Wayland, regardless of shell extensions. The issue happens after a few days (or hours) of usage and goes away as soon as you reload GNOME Shell (alt+F2, "r", enter). That's already pretty conspicuous to begin with.

Nevertheless, to make sure to rule out remaining hypotheses, lately I have tested with the latest Wayland version (still affected as of 3.22.x), and then compared with elementary's "Gala" window manager running on the Pantheon session/desktop environment on the same distro (Fedora 25) where I am normally running GNOME Shell (to factor out any variations in the graphics/kernel/libraries/etc.)... and experienced zero performance issues with Gala over the course of an entire month of usage. This pretty much rules out everything besides GNOME Shell, in my view.


To go with my claims above, I am providing some additional data in the form of sysprof output on two machines running only native GNOME apps (not even Firefox); the benchmark was simply moving windows around or entering/exiting the Shell overview mode while the performance problem is occurring (i.e. after a few days of uptime).

I hope that this will be sufficient in proving the existence of the problem and helping find the root cause at last.
Comment 179 Christian Hergert 2016-12-14 06:09:13 UTC
I'll just comment on sysprof for a moment:

Sadly, sysprof does not currently append the symbol information to the .syscap file, so the symbols from the capture will likely be not very useful to others since they will have inode mismatches. (Fixing this is on my queue for 3.24).

However, if you expand to some of the expensive parts, you can use the "screenshot" feature in the window menu to get textual output for c&p.

Unfortunately, I also haven't yet got GJS profiling integrated. But I expect that if we could profile GJS we'll find some interesting things. (I did when testing it last winter briefly).

Yet a third piece I need to add to sysprof to simplify the troubleshooting process is to finish the "profile comparisons" (wip/chergert/compare branch).

After all of those, tracking this down should be simpler. But please don't let that prevent anyone from making progress :)
Comment 180 Vasilis Liaskovitis 2017-01-27 11:15:35 UTC
Created attachment 344393 [details]
valgrind log gnome-shell 3.20.4

I am seeing this major leak as well, and I am attaching a valgrind memcheck report  (partial one, due to size)

This is on:
gnome-shell 3.20.4
mutter 3.20.3

but leaks should also be relevant for master.

the benchmark is similar to comment #178, simply entering/exiting the Shell overview mode, opening a few apps (image-viewer, screenshot, folder viewer), and moving windows around. 

From large "possibly lost" entries, it looks like fbos are leaked from various places: texture_tower_revalidate, texture_tower_create_texture, meta_background_get_texture, update_fbo. I am not sure if these can be ignored as false positives or if they could indicate root causes.
Comment 181 Hussam Al-Tayeb 2017-02-10 21:50:18 UTC
It took a week of learning how to do this a bit more every night but I managed to get a valgrind log with a very easily reproduce-able gradual 2 to 4MB leak.
in bug 778368 if anyone is interested.
Direct link to valgrind log: https://bugzilla.gnome.org/attachment.cgi?id=345483
My uneducated guess is Cogl and lower at fault.
Comment 182 Jean-François Fortin Tam 2017-02-15 14:30:43 UTC
Wow, that's interesting... simply having gnome-system-monitor open and filtering down to "gnome-shell", I can confirm that every time you open the activities overview (pressing the Super key or whatnot), memory usage increases by a few hundred kilobytes to a few megabytes and never goes down.

Not only that, you get nearly-continuously increasing memory usage by repeatedly alt-tabbing. It's hilarious. I'd screencast it, but that throws off the numbers because screencasting eats the memory like crazy as well ;)

Even running with all animations disabled, I've been seeing major slowdowns after a few days of use... on an Intel Iris 6100 (Broadwell GT3 / i7 5557U), by no means a slow machine.
Comment 183 Hussam Al-Tayeb 2017-02-19 12:43:20 UTC
I added an hourly use cronjob that export DISPLAY, XAUTHORITY, and DBUS_SESSION_BUS_ADDRESS and runs:

/usr/bin/dbus-send --type=method_call --print-reply --dest=org.gnome.Shell /org/gnome/Shell org.gnome.Shell.Eval string:'global.reexec_self()'

Very ugly workaround but unless I do so, I am reaching 700MB an hour on gnome-shell 3.23.90.

2.22.xx was much better in this regard. It used to take 24 hours to cross the 350MB barrier.

I understand most developers are volunteers so if anyone finds time to investigate and suggest a fix, it would be very nice :)


(In reply to Jean-François Fortin Tam from comment #182)
> Not only that, you get nearly-continuously increasing memory usage by
> repeatedly alt-tabbing. It's hilarious. I'd screencast it, but that throws
> off the numbers because screencasting eats the memory like crazy as well ;)

I mitigated the screencasting memory usage by editing src/shell-recorder.c and changing vp9 to vp8

-#define DEFAULT_PIPELINE "vp9enc min_quantizer=13 max_quantizer=13 cpu-used=5 deadline=1000000 threads=%T ! queue ! webmmux"
+#define DEFAULT_PIPELINE "vp8enc min_quantizer=13 max_quantizer=13 cpu-used=5 deadline=1000000 threads=%T ! queue ! webmmux"
Comment 184 xiaoguang wang 2017-02-20 05:22:08 UTC
Created attachment 346225 [details] [review]
Fix memory leak in meta_prop_get_values

valgrind log:

32 bytes in 2 blocks are definitely lost in loss record 15,974 of 51,187
   at 0x4C29160: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x795D41F: g_malloc (gmem.c:94)
   by 0x60AD327: async_get_property_finish (xprops.c:218)
   by 0x60ADCDD: meta_prop_get_values (xprops.c:945)
   by 0x60A1E83: meta_group_reload_properties (group-props.c:78)
   by 0x60A21C8: meta_group_new (group.c:84)
   by 0x60A2421: meta_window_compute_group (group.c:179)
   by 0x60A668B: reload_wm_hints (window-props.c:1596)
   by 0x60A7606: reload_prop_value (window-props.c:199)
   by 0x60A7606: meta_window_load_initial_properties (window-props.c:163) *****
   by 0x60AAF75: meta_window_x11_manage (window-x11.c:519) *****
   by 0x60946F9: _meta_window_shared_new (window.c:1024)
   by 0x60ABA5B: meta_window_x11_new (window-x11.c:3002)
   by 0x60A0B22: handle_other_xevent (events.c:1371)
   by 0x60A17DA: meta_display_handle_xevent (events.c:1769)
   by 0x60A17DA: xevent_filter (events.c:1808)
   by 0xAF98C70: gdk_event_apply_filters (gdkeventsource.c:79)
   by 0xAF98F35: gdk_event_source_translate_event (gdkeventsource.c:198)
   by 0xAF98F35: _gdk_x11_display_queue_events (gdkeventsource.c:341)
   by 0xAF68E48: gdk_display_get_event (gdkdisplay.c:396)
   by 0xAF98CE1: gdk_event_source_dispatch (gdkeventsource.c:363)
   by 0x7958133: g_main_dispatch (gmain.c:3154)
   by 0x7958133: g_main_context_dispatch (gmain.c:3769)
   by 0x7958387: g_main_context_iterate.isra.24 (gmain.c:3840)
   by 0x7958649: g_main_loop_run (gmain.c:4034)
   by 0x6082F3B: meta_run (main.c:537)
   by 0x402336: main (main.c:471)
Comment 185 Hussam Al-Tayeb 2017-02-21 15:00:04 UTC
Created attachment 346365 [details]
valgrind log with  xiaoguang wang's patch applied.

Hi :)
I got a new valgrind log with your patch applied. It seems to cover librsvg and gdk-pixbuf a lot.
Comment 186 Rui Matos 2017-02-21 15:15:15 UTC
Review of attachment 346225 [details] [review]:

Thanks for pointing out this problem. This isn't the right fix though because in some cases the original buffer is returned in the MetaPropValue and thus must only be free'd by the caller.
Comment 187 Rui Matos 2017-02-21 15:16:47 UTC
Created attachment 346366 [details] [review]
x11/xprops: Plug a few memory leaks

Commits 6dbec6f8, 734402e1 and f041b35b introduced memory leaks by
switching to returning copies instead of the original buffers but
forgetting to free those original buffers.

Some error cases were also not freeing the ->prop buffer as they
should.
Comment 188 Rui Matos 2017-02-21 15:24:11 UTC
(In reply to Hussam Al-Tayeb from comment #185)
> I got a new valgrind log with your patch applied.

Note that those xprops leaks are very small and would never account to multiple megabytes unless you perhaps if your session is months old and you open/close windows a lot.

> It seems to cover librsvg
> and gdk-pixbuf a lot.

Can you re-run this capture with the --num-callers=100 valgrind option?

Also, beyond those librsvg traces I see some big possibly lost buffers seemingly allocated by the nvidia driver. I'm afraid we can't fix those.
Comment 189 Hussam Al-Tayeb 2017-02-21 15:53:17 UTC
Created attachment 346368 [details]
new valgrind log with num-callers=100

Ok, this generated a 98MB file which I compressed to under 1MB.

Regarding the nvidia issue, I recently asked aaron plattner (nvidia developer) and he said I was not exiting gnome-shell correctly which is why those buffers where not correctly freed.

What would be the correct way to gracefully exit gnome-shell when ran from valgrind?

Thank you.
Comment 190 Hussam Al-Tayeb 2017-02-21 15:54:47 UTC
tail -n100 valgrind.log

==5023== 49,980,192 (36,672,328 direct, 13,307,864 indirect) bytes in 59,533 blocks are definitely lost in loss record 105,805 of 105,805
==5023==    at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5023==    by 0x7846C48: g_malloc (gmem.c:94)
==5023==    by 0x785F122: g_slice_alloc (gslice.c:1025)
==5023==    by 0x48E1442A: rsvg_state_new (rsvg-styles.c:204)
==5023==    by 0x48E17CC8: rsvg_new_node_chars (rsvg-base.c:895)
==5023==    by 0x48E17CC8: rsvg_characters_impl (rsvg-base.c:962)
==5023==    by 0x13ADB58A: xmlParseCharData (parser.c:4561)
==5023==    by 0x13AE86C4: xmlParseTryOrFinish (parser.c:11757)
==5023==    by 0x13AE936A: xmlParseChunk (parser.c:12496)
==5023==    by 0x48E19D6E: rsvg_handle_write_impl (rsvg-base.c:1336)
==5023==    by 0x48E19D6E: rsvg_handle_write (rsvg-base.c:1915)
==5023==    by 0x3A267CE2: gdk_pixbuf__svg_image_load_increment (io-svg.c:133)
==5023==    by 0xAD44083: gdk_pixbuf_loader_write (gdk-pixbuf-loader.c:524)
==5023==    by 0xAD3F5CA: load_from_stream (gdk-pixbuf-io.c:1454)
==5023==    by 0xAD4176C: gdk_pixbuf_new_from_stream_at_scale (gdk-pixbuf-io.c:1539)
==5023==    by 0x657E5D5: icon_info_ensure_scale_and_pixbuf (gtkicontheme.c:3940)
==5023==    by 0x657E80B: load_icon_thread (gtkicontheme.c:4161)
==5023==    by 0x729062C: g_task_thread_pool_thread (gtask.c:1328)
==5023==    by 0x7869D9D: g_thread_pool_thread_proxy (gthreadpool.c:307)
==5023==    by 0x78693A4: g_thread_proxy (gthread.c:784)
==5023==    by 0x7B124D6: start_thread (in /usr/lib/libpthread-2.25.so)
==5023==    by 0x7E1508E: clone (in /usr/lib/libc-2.25.so)
==5023== 
==5023== LEAK SUMMARY:
==5023==    definitely lost: 70,725,335 bytes in 286,872 blocks
==5023==    indirectly lost: 28,676,958 bytes in 867,863 blocks
==5023==      possibly lost: 91,368,143 bytes in 22,488 blocks
==5023==    still reachable: 35,428,158 bytes in 362,679 blocks
==5023==                       of which reachable via heuristic:
==5023==                         length64           : 16,744 bytes in 232 blocks
==5023==                         newarray           : 31,872 bytes in 105 blocks
==5023==         suppressed: 646,085 bytes in 5,947 blocks
==5023== Reachable blocks (those to which a pointer was found) are not shown.
==5023== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5023== 
==5023== For counts of detected and suppressed errors, rerun with: -v
==5023== Use --track-origins=yes to see where uninitialised values come from
==5023== ERROR SUMMARY: 25425 errors from 24786 contexts (suppressed: 29 from 29)

I am really sorry the file turned out to be so large...
Comment 191 Rui Matos 2017-02-21 16:14:44 UTC
(In reply to Hussam Al-Tayeb from comment #189)
> Created attachment 346368 [details]
> new valgrind log with num-callers=100
> 
> Ok, this generated a 98MB file which I compressed to under 1MB.

Thanks.

> Regarding the nvidia issue, I recently asked aaron plattner (nvidia
> developer) and he said I was not exiting gnome-shell correctly which is why
> those buffers where not correctly freed.
> 
> What would be the correct way to gracefully exit gnome-shell when ran from
> valgrind?

Starting a new gnome-shell instance with --replace will cause the older instance to exit cleanly by returning from main(). Alternatively you can just 'kill <gnome-shell pid>' which also causes the process to return from main() but then you won't have a window manager.
Comment 192 Hussam Al-Tayeb 2017-02-21 16:54:40 UTC
Unfortunately, gnome-shell --replace is crashing the valgrind instance of gnome-shell.
https://paste.gnome.org/pqy8hhnbp/qglmtc/raw
Comment 193 Florian Müllner 2017-02-21 17:15:43 UTC
Review of attachment 346366 [details] [review]:

LGTM
Comment 194 Hussam Al-Tayeb 2017-02-21 17:41:15 UTC
Created attachment 346379 [details]
valgrind log with debug mesa (nouveau)

Ok, I built a debug mesa (nouveau) and tried it.

==1080==    definitely lost: 69,454,378 bytes in 253,676 blocks
==1080==    indirectly lost: 28,694,621 bytes in 866,350 blocks

Rebooting to NVIDIA binary blob now...
Comment 195 Rui Matos 2017-02-21 17:49:58 UTC
(In reply to Hussam Al-Tayeb from comment #194)
> Created attachment 346379 [details]
> valgrind log with debug mesa (nouveau)

Which librsvg version are you using?
Comment 196 Hussam Al-Tayeb 2017-02-21 17:59:59 UTC
(In reply to Rui Matos from comment #195)
> (In reply to Hussam Al-Tayeb from comment #194)
> > Created attachment 346379 [details]
> > valgrind log with debug mesa (nouveau)
> 
> Which librsvg version are you using?

latest git master branch.
Comment 197 Rui Matos 2017-02-21 19:03:06 UTC
Comment on attachment 346366 [details] [review]
x11/xprops: Plug a few memory leaks

Attachment 346366 [details] pushed as 5ba38a4 - x11/xprops: Plug a few memory leaks
Comment 198 Rui Matos 2017-02-21 19:21:46 UTC
(In reply to Hussam Al-Tayeb from comment #196)
> > Which librsvg version are you using?
> 
> latest git master branch.

Can you try the last 2.40.x version?

Also, can you try patching gnome-shell with this diff:

diff --git a/src/main.c b/src/main.c
index 78a300d..e1c9261 100644
--- a/src/main.c
+++ b/src/main.c
@@ -474,6 +474,7 @@ main (int argc, char **argv)
   _shell_global_destroy_gjs_context (shell_global_get ());
   g_object_unref (shell_global_get ());
   g_object_unref (sender);
+  g_object_run_dispose (G_OBJECT (st_texture_cache_get_default ()));
 
   return ecode;
 }

It should free all the cached icons before the process exits which I suspect will clean up a few of those valgrind reports.
Comment 199 Hussam Al-Tayeb 2017-02-21 19:33:29 UTC
(In reply to Rui Matos from comment #198)
> (In reply to Hussam Al-Tayeb from comment #196)
> > > Which librsvg version are you using?
> > 
> > latest git master branch.
> 
> Can you try the last 2.40.x version?

That does sound like a smart idea.

> Also, can you try patching gnome-shell with this diff:
> 
> diff --git a/src/main.c b/src/main.c
> index 78a300d..e1c9261 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -474,6 +474,7 @@ main (int argc, char **argv)
>    _shell_global_destroy_gjs_context (shell_global_get ());
>    g_object_unref (shell_global_get ());
>    g_object_unref (sender);
> +  g_object_run_dispose (G_OBJECT (st_texture_cache_get_default ()));
>  
>    return ecode;
>  }
> 
> It should free all the cached icons before the process exits which I suspect
> will clean up a few of those valgrind reports.

I'll do that as well.
Comment 200 Hussam Al-Tayeb 2017-02-21 20:08:25 UTC
Ok, this is what I see now:
https://paste.gnome.org/pchexj5gu/xuxq5p/raw
The leak itself is still there. Could it be something valgrind cannot detect? Perhaps caching textures multiple times?
Comment 201 Florian Müllner 2017-02-21 20:27:21 UTC
I filed bug 779036 for:

==21581== 904,176 bytes in 12,558 blocks are definitely lost in loss record 33,975 of 33,989
==21581==    at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21581==    by 0x7846C48: g_malloc (gmem.c:94)
==21581==    by 0x785F122: g_slice_alloc (gslice.c:1025)
==21581==    by 0x59DAF19: ??? (in /usr/lib/libgirepository-1.0.so.1.0.0)
==21581==    by 0x552E21A: get_field_info (boxed.cpp:534)
==21581==    by 0x552E21A: ??? (boxed.cpp:812)

and

==21581== 686,232 bytes in 9,531 blocks are definitely lost in loss record 33,967 of 33,989
==21581==    at 0x4C2AB8D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21581==    by 0x7846C48: g_malloc (gmem.c:94)
==21581==    by 0x785F122: g_slice_alloc (gslice.c:1025)
==21581==    by 0x59DAF19: ??? (in /usr/lib/libgirepository-1.0.so.1.0.0)
==21581==    by 0x552D96D: get_field_info (boxed.cpp:534)
==21581==    by 0x552D96D: ??? (boxed.cpp:638)
Comment 202 luke.nukem.jones@gmail.com 2017-03-16 22:39:39 UTC
Created attachment 348133 [details]
valgrind - gjs-1.47.92, gnome-shell-3.23.91

Run with;

valgrind --log-file="valgrind-shell" --tool=memcheck --track-origins=yes --leak-check=full --show-leak-kinds=definite,possible --leak-resolution=med --num-callers=40 gnome-shell -r
Comment 203 Carlos Garnacho 2017-04-07 10:29:55 UTC
Created attachment 349454 [details] [review]
st-texture-cache: Plug some pixbuf refcount leaks on async operations

When extracting the sliced image, the GTask grants data ownership on
g_task_propagate_*, so the pixbuf list must be properly freed. On async
load, we just left a dangling reference when returning on the async
task.
Comment 204 Hussam Al-Tayeb 2017-04-07 11:40:49 UTC
Created attachment 349459 [details]
Valgrind log after applying above patch.
Comment 205 Florian Müllner 2017-04-07 11:41:08 UTC
Review of attachment 349454 [details] [review]:

Eeeks, LGTM
Comment 206 Carlos Garnacho 2017-04-07 12:34:09 UTC
Comment on attachment 349454 [details] [review]
st-texture-cache: Plug some pixbuf refcount leaks on async operations

Thanks! pushed to master and gnome-3-24

Attachment 349454 [details] pushed as 44e80f4 - st-texture-cache: Plug some pixbuf refcount leaks on async operations
Comment 207 Jean-François Fortin Tam 2017-08-04 14:42:23 UTC
Just for the record (to make it clear the committed fix in comment #206 is probably a step in the right direction, but not "the" solution): problem still occurs with the 3.24 stack on a fully up to date Fedora 26.
Comment 208 Hussam Al-Tayeb 2017-12-31 10:45:07 UTC
(In reply to Rui Matos from comment #198)
> (In reply to Hussam Al-Tayeb from comment #196)
> > > Which librsvg version are you using?
> > 
> > latest git master branch.
> 
> Can you try the last 2.40.x version?
> 
> Also, can you try patching gnome-shell with this diff:
> 
> diff --git a/src/main.c b/src/main.c
> index 78a300d..e1c9261 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -474,6 +474,7 @@ main (int argc, char **argv)
>    _shell_global_destroy_gjs_context (shell_global_get ());
>    g_object_unref (shell_global_get ());
>    g_object_unref (sender);
> +  g_object_run_dispose (G_OBJECT (st_texture_cache_get_default ()));
>  
>    return ecode;
>  }
> 
> It should free all the cached icons before the process exits which I suspect
> will clean up a few of those valgrind reports.

Hi. This particular patch now causes a crash on exit. https://paste.gnome.org/pf0lubvug
Comment 209 Alexandre Bique 2018-02-09 10:10:35 UTC
Hi, I confirm the bug on an up to date Archlinux desktop.
After a few days, gnome-shell has more than a GB of resident memory!
Comment 210 André Klapper 2018-02-09 10:20:13 UTC
(In reply to Alexandre Bique from comment #209)
> Hi, I confirm the bug on an up to date Archlinux desktop.
> After a few days, gnome-shell has more than a GB of resident memory!

Please provide both version information and valgrind logs.
Comment 211 Ralf 2018-02-26 21:16:57 UTC
Created attachment 368979 [details]
memcheck output

This is with the Debian testing versions of gnome-shell 3.26.2-4, libmutter 3.26.2-1, gjs 1.50.3-2.  Just running gnome-shell normally and opening htop, I can see the memory usage grow if I open and close the system menu (with volume, WiFi settings etc. in it) several times.

I disabled extensions and ran

  valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --log-file=vgdump gnome-shell --replace

I opened and closed the system menu several times and then ran `gnome-shell --replace` in another terminal.  This produced the attached output.  Does this help? Let me know if there is further information I can provide.
Comment 212 Carlos Garnacho 2018-02-27 14:01:07 UTC
(In reply to Ralf from comment #211)
> Created attachment 368979 [details]
> memcheck output
> 
> This is with the Debian testing versions of gnome-shell 3.26.2-4, libmutter
> 3.26.2-1, gjs 1.50.3-2.  Just running gnome-shell normally and opening htop,
> I can see the memory usage grow if I open and close the system menu (with
> volume, WiFi settings etc. in it) several times.
> 
> I disabled extensions and ran
> 
>   valgrind --tool=memcheck --leak-check=full --leak-resolution=high
> --num-callers=20 --log-file=vgdump gnome-shell --replace
> 
> I opened and closed the system menu several times and then ran `gnome-shell
> --replace` in another terminal.  This produced the attached output.  Does
> this help? Let me know if there is further information I can provide.

Thanks, the steps you did to get the information are all correct. However, you didn't seem to catch gnome-shell doing anything that leaked seriously (~40K overall, most of that being false positives due to glib/fontconfig/mesa permanent caches).

I have local patches for some real leaks spotted there (eg. bug #793878), but they are all rather minuscule.
Comment 213 Ralf 2018-02-27 14:30:01 UTC
> Thanks, the steps you did to get the information are all correct. However, you didn't seem to catch gnome-shell doing anything that leaked seriously (~40K overall, most of that being false positives due to glib/fontconfig/mesa permanent caches).

Not sure why it doesn't show up.  When I just look at the "RES" column in htop, I can see it rise by around 3MB for 5 times of opening and closing the system menu.  I already noticed that after ~7 days of uptime, the entire shell gets noticeably laggy -- animations drop frames, latency increases.
Comment 214 Jonas Ådahl 2018-03-12 12:25:30 UTC
(In reply to Ralf from comment #213)
> > Thanks, the steps you did to get the information are all correct. However, you didn't seem to catch gnome-shell doing anything that leaked seriously (~40K overall, most of that being false positives due to glib/fontconfig/mesa permanent caches).
> 
> Not sure why it doesn't show up.  When I just look at the "RES" column in
> htop, I can see it rise by around 3MB for 5 times of opening and closing the
> system menu.  I already noticed that after ~7 days of uptime, the entire
> shell gets noticeably laggy -- animations drop frames, latency increases.

This is an interesting discovery. I can confirm that the same thing happens here. I don't think it's a leak though; opening "looking glass" (alt-F2, then "lg") and running System.gc() makes the usage go down again to more or less what it was before openin gand closing the menu again and again. Is it the same for you?
Comment 215 Chad Rodrigue 2018-03-14 04:45:42 UTC
Doesn't help for me.  I just get "undefined" as the response.  Memory stays the same.  

If this bug were a child it would be able to read by now.  ;-)  Long time subscriber, though, and it's always interesting to see this one show up in my email.
Comment 216 Ralf 2018-03-14 18:06:35 UTC
> I just get "undefined" as the response.

Yeah, same here.  I guess my gnome-shell is too old?
Comment 217 Florian Müllner 2018-03-14 18:11:55 UTC
(In reply to Ralf from comment #216)
> > I just get "undefined" as the response.
> 
> Yeah, same here.  I guess my gnome-shell is too old?

No, it just means that the function doesn't have a return value.
Comment 218 Ralf 2018-03-14 18:36:16 UTC
Ah, I see.

Running System.gc() decreases memory usage slightly but far from back to where it started.  My shell that has been running for 2 days was at >500MB.  The freshly restarted shell consumes around 180MB; after clicking the menu many times it went up to 225MB; System.gc() reduced that to 218MB.  By now (as I am typing this, just a few minutes later), it's already at 260MB; System.gc() does not help.
Comment 219 Florian Müllner 2018-10-22 18:57:55 UTC
I'll take the progress made with gjs' garbage collection[0] as an opportunity to close this bug - an "everything-memory-related" catch-all report isn't actionable, so any new issues that surface should be reported separately under https://gitlab.gnome.org/GNOME/gnome-shell/issues.

[0] https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/
Comment 220 Hussam Al-Tayeb 2018-10-22 19:17:21 UTC
Sorry, I meant to remove myself from CC list and pressed something else by mistake.