Bug 672117 - Mutter seems to leak a lot of memory
Mutter seems to leak a lot of memory
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
Depends On:
Blocks: F15GNOMEfail
  Show dependency treegraph
 
Reported: 2011-01-23 19:55 EST by Zdenek Kabelac
Modified: 2014-09-29 14:41 EDT (History)
28 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-29 14:41:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Memory map of running mutter process (89.37 KB, text/plain)
2011-01-23 19:55 EST, Zdenek Kabelac
no flags Details
Valgrind trace (2.97 MB, application/x-gzip)
2011-07-22 15:25 EDT, Zdenek Kabelac
no flags Details
gnome-shell valgrind output (63 bytes, text/plain)
2011-07-23 12:38 EDT, Jack Waterworth
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 642652 None None None Never

  None (edit)
Description Zdenek Kabelac 2011-01-23 19:55:22 EST
Created attachment 474879 [details]
Memory map of running mutter process

Description of problem:

During the usage of gnome-shell and mutter over last couple days,
I'm noticing a lot of memory goes in mutter process:

Attaching memory map. Top show 550M is lost.
 
Version-Release number of selected component (if applicable):
mutter-2.91.5-1.fc15.x86_64


How reproducible:
Just normal usage with firefox, thunderbird, pidgin, pdf/image view for couple hours.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:
I'm not saying 640kb should be enough for everybody - but using more then 20MB for window manager looks weird.

Additional info:
Comment 1 Zdenek Kabelac 2011-02-16 11:10:30 EST
Just a wild guess by watching 'top' RES memory it seems like 1MB is lost per 3 switches between Activity and desktop.
Comment 2 Zdenek Kabelac 2011-02-21 04:51:55 EST
As a workaround when the size of consumed memory by mutter grow to big is restart through  gnome-shell console  -  Alt+F2  and use 'r' command.

However usually mutter manages to kill itself sooner through memory corruption bugs.
Comment 3 Peter Robinson 2011-02-21 05:01:56 EST
> However usually mutter manages to kill itself sooner through memory corruption
> bugs.

Is there abrt bugs reported for these crashes?
Comment 4 Zdenek Kabelac 2011-02-21 05:41:36 EST
I'm not sure whether some of those many abrt bug reports in mutter bug listing is equal to my report Bug 679015 - if it's - feel free to close as duplicate.
Comment 5 Zdenek Kabelac 2011-03-30 04:22:26 EDT
As an update here - gnome-shell - which seems like a old/new name for mutter now at least on the first sight does not produce such major memory leaks - seems like it grows somehow slowly over the time - but definitely no 1MB per 3 switches of Activity.
Comment 6 Adam Williamson 2011-04-23 10:54:19 EDT
as I noted on the -desktop list, I noticed Shell using 800MB of RAM on this system yesterday, after an uptime of 4 days and effective uptime (minus suspends) of around 2.

I restarted it at that time and it's now at 152MB, I'll keep an eye and see where it goes from there.
Comment 7 Callum Lerwick 2011-05-16 14:33:59 EDT
I'm seeing problems like this, today, with an up to date F15 beta. Both Xorg and gnome-shell seem to like to bloat up over time, eating 100's of megs of RAM, eventually causing continuous swapping and making the system unusable for even basic web browsing tasks. gnome-shell can be restarted, bringing it back down to ~50mb RAM, but this does nothing about Xorg. Eventually Xorg bloated up to over 400mb resident RAM, and would not go down even if I killed off all apps and restarted gnome-shell. The only way to make the system usable again is to log out so Xorg restarts. The only thing I'm doing is using Chromium. Even with only one tab open, Chromium is unusable in this state.

The "fallback" "experience" does not seem to have this problem. But if I'm going to have to put up with this crippled "experience", I'd rather go back to F14.

This is on an emachines m6805 laptop, with 1.25gb RAM, Athlon 64 3000+, with mobile Radeon 9600 and 64mb dedicated VRAM, running 64bit Fedora 15.
Comment 8 Adam Williamson 2011-05-16 16:04:04 EDT
to bring this up to date for me - i'm still seeing gnome-shell leak too, the fix for https://bugzilla.gnome.org/show_bug.cgi?id=642652 didn't seem to help (or at least, didn't entirely fix all leaks) when I applied it locally. I haven't noticed X getting particularly huge, though I wasn't actively tracking it. I have an uptime of just over 3 days in my current session, some of which will have been spent suspended, and Shell is at 349MB, X at 118MB. I promised Colin I'd run shell through valgrind to try and pinpoint what leaks I'm still hitting, but haven't had time yet, with F15 release validation.

I'm gonna note this as CommonBugs so we can document the workaround (kill gnome-shell every so often).



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 9 Thierry Vignaud 2011-05-18 05:21:41 EDT
Same for me with an up to date FC15
gnome-shell starts at 75m of RSS but reachs ~300Mb after a couple days (having only firefox, a terminal and emacs) on GeForce 100.
Comment 10 Adam Williamson 2011-05-24 10:24:31 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 11 Fidtiriadi H. 2011-07-05 02:20:44 EDT
same goes to me. gnome-shell taking too much ram over the times. Turning off every extensions and use all the default (themes,icons,cursor) to find the culprit. seeing that the memories always goes up whenever i hit the "hot corner" to go to "activities", sometimes as much as 5mb after around 5 switches between desktop and activities. using alt-tab doesn't increase the memory usage.
Comment 12 Peter Robinson 2011-07-05 03:26:26 EDT
I think this is gnome-shell directly as opposed to mutter
Comment 13 Fidtiriadi H. 2011-07-05 03:46:03 EDT
(In reply to comment #12)
> I think this is gnome-shell directly as opposed to mutter

I think everyone is confused with gnome-shell, mutter thing. see; 

http://fedoraproject.org/wiki/Common_F15_bugs#System_memory_in_use_rises_constantly_.28memory_leak.29_when_using_GNOME_Shell

the title is "System memory in use rises constantly (memory leak) when using GNOME Shell" and the link lead to this bug report.

these start to confusing me..nevertheless, this bug is extremely annoying, had to restart shell over and over again. In 10 switches between desktop and activities, it reach 125mb here. :(
Comment 14 Peter Robinson 2011-07-05 06:03:15 EDT
> I think everyone is confused with gnome-shell, mutter thing. see; 

Nope. gnome-shell is essentially a plugin loaded by mutter.

> the title is "System memory in use rises constantly (memory leak) when using
> GNOME Shell" and the link lead to this bug report.

I'm aware of that.

> these start to confusing me..nevertheless, this bug is extremely annoying, had
> to restart shell over and over again. In 10 switches between desktop and
> activities, it reach 125mb here. :(

Consider yourself lucky. I've had it up to 2Gb.
Comment 15 Hicham HAOUARI 2011-07-05 07:26:26 EDT
@Owen Taylor :

Can you give a comment on this ?
Comment 16 Owen Taylor 2011-07-05 14:14:59 EDT
Initial increase in memory usage is expected, as with any garbage collected application. We probably don't have garbage collection perfectly tuned.

I haven't seen a lot of evidence that clearly points to big memory leaks - though I'm sure that there are *some* memory leaks - any significant application has some memory leaks.

If someone (not scared of coding) wants to get involved in improving memory performance of gnome-shell or in improving quantification of what's a leak and what isn't a leak, please come and find me (otaylor) or walters on GIMPnet:#gnome-shell.
Comment 17 Adam Williamson 2011-07-05 14:36:55 EDT
Owen: the symptom is pretty clear-cut: for multiple reporters, gnome-shell memory usage increases steadily over time, to clearly unacceptable levels in some cases (see https://bugzilla.redhat.com/show_bug.cgi?id=672117#c14 ). Whether the cause is something that would correctly be described as a 'leak' or not seems moot: the crucial issue is the steadily increasing and excessive level of memory use.
Comment 18 Owen Taylor 2011-07-05 14:51:48 EDT
(In reply to comment #17)
> Owen: the symptom is pretty clear-cut: for multiple reporters, gnome-shell
> memory usage increases steadily over time, to clearly unacceptable levels in
> some cases (see https://bugzilla.redhat.com/show_bug.cgi?id=672117#c14 ).
> Whether the cause is something that would correctly be described as a 'leak' or
> not seems moot: the crucial issue is the steadily increasing and excessive
> level of memory use.

Memory measurement is *incredibly* tricky, especially when there is garbage collection and CPU and GPU memory involved. The only *clear* sign from top that you have a memory leak is:

 - You do something repeatedly
 - The RES (resident) field increases indefinitely and linearly

125MB RES is pretty much line with my expectations for the shell running a few days. There's no way I can interpret "I've had it up to 2Gb". If someone finds a reliable way to trigger gigabytes of resident memory usage reproduciblely, that would be great progress and worth and upstream bug report.
Comment 19 Adam Williamson 2011-07-05 15:02:58 EDT
I can't speak to Peter's experience, but res is of course the field I look at it, and as I've said, my experience with F15 is that it would increase constantly throughout an active session, starting around 80MB but increasing past 300MB over time. I have no reason to believe it wouldn't have risen further if I'd let Shell run longer.

I'm on Shell 3.1.3 on Rawhide now, I'll keep an eye and see how that behaves.
Comment 20 Herman Boomsma 2011-07-05 15:04:14 EDT
I can confirm this bug, it only takes like 15 minutes to make G-shell use > 200mb on both my laptop and desktop. On my laptop I only have 3gb, so I had to switch  to fallback-mode to keep using the software I was using in Gnome 2. 

It kept eating memory, making the system swap everything else. So I was left without any free memory and a very slow system. Switching to G-shell fallback mode made my life pleasant again. (using the same video driver in g-shell and fallback mode, being radeon).
I have seen this behaviour in beta and still in current version.

I had to restart gnome shell like every 12 hours to keep everything 'speedy'. (switching to fallback mode gave me great speed improvement). This has been reported on IRC quite a lot of times, some people consider it normal gnome-shell behaviour and are very used to the 'alt+f2, r, enter' procedure.
Comment 21 Peter Robinson 2011-07-06 03:59:09 EDT
(In reply to comment #19)
> I can't speak to Peter's experience, but res is of course the field I look at

Mine is RES as well as reported by atop/top. My shell had been running for 3-5 days and had gone through a number (likely around a dozen) of suspend/resume cycles. GPU is Intel Ironlake if that makes any difference. Theme is default Fedora 15.
Comment 22 Callum Lerwick 2011-07-18 17:51:37 EDT
Following up on comment #7, the Xorg problem seemed to have gotten fixed at some point during pre-release, though I suspect it was triggered by me enabling Chrome's GPU acceleration, which I disabled again after having these issues. Firefox still likes to make Xorg occasionally bloat up and never go down even if I close firefox, but it has always done that...

gnome-shell is still a problem. Regardless of the reasons, a major point here is the base memory requirements of GNOME 3 have DRASTICALLY increased over GNOME 2, for even the most basic desktop functionality.

This very well may be a case of "Sorry, the relentless march of bloat goes on. Upgrade or perish!"

Sigh.

The old "Linux is less bloated!" slogan is as dead as Atari's "Power with the Price".

Looks like I will be sticking with Fedora 14, and when it goes EoL I'm just SOL. I'm getting real sick of having to buy new hardware for no reason other than just keeping up with Fedora's bloat-flation.
Comment 23 Callum Lerwick 2011-07-18 17:55:29 EDT
("Power without the price", that is)
Comment 24 Peter Robinson 2011-07-18 19:06:31 EDT
(In reply to comment #22)
> Following up on comment #7, the Xorg problem seemed to have gotten fixed at
> some point during pre-release, though I suspect it was triggered by me enabling
> Chrome's GPU acceleration, which I disabled again after having these issues.
> Firefox still likes to make Xorg occasionally bloat up and never go down even
> if I close firefox, but it has always done that...
> 
> gnome-shell is still a problem. Regardless of the reasons, a major point here
> is the base memory requirements of GNOME 3 have DRASTICALLY increased over
> GNOME 2, for even the most basic desktop functionality.
> 
> This very well may be a case of "Sorry, the relentless march of bloat goes on.
> Upgrade or perish!"
> 
> Sigh.
> 
> The old "Linux is less bloated!" slogan is as dead as Atari's "Power with the
> Price".
> 
> Looks like I will be sticking with Fedora 14, and when it goes EoL I'm just
> SOL. I'm getting real sick of having to buy new hardware for no reason other
> than just keeping up with Fedora's bloat-flation.

I'm going to call bullshit in your comments here. Most of the 3D stuff should be using graphics memory, so in fact it should likely be a reduction as rendering should be offloaded. Its not.
Comment 25 Callum Lerwick 2011-07-18 19:43:10 EDT
Whats the smallest-spec machine you've used F15 on? Try and use (that is, really USE. Heavy browsing for a couple of days at least.) F15 on the same or similar hardware, and then you can call bullshit.

Like I said, m6805 laptop, 1.25gb RAM, Athlon 64 3000+, mobile Radeon 9600 64mb dedicated VRAM (not shared!), running 64bit Fedora 15. Was a high end laptop when it was new in 2004. It's perfectly capable of playing ATSC HD video from my mythtv backend. But it's over 5 years old so I guess it's garbage now.

Anyway, I've figured out that Fedora runs beautifully on my new Toshiba L645D-S4056 in VirtualBox in Windows 7, so the m6805 doesn't need to be anything other than a MythTV frontend now. Problem solved.

(I need a native windows machine to be able to run Ableton Live and WoW acceptably. Wine just doesn't cut it.)
Comment 26 Adam Williamson 2011-07-18 19:50:30 EDT
this is a bug reporting mechanism, not a discussion forum. please use a more appropriate venue for general discussion, and restrict this bug report to discussion of the actual bug under discussion.

fwiw, I still seem to see gnome-shell process increasing in RES memory use when used normally, but I tried running it through valgrind for a day and didn't get any clear leak notifications. and interestingly, when running through valgrind, the RES usage is initially far higher - on the order of 650MB - but does not seem to increase over time.
Comment 27 Jack Waterworth 2011-07-20 00:29:23 EDT
I'm having the same problem on two machines.

$ ps aux | grep bin/gnome-shell | head -1
jack 3538 1.3 23.8 2758084 983580 ? Sl Jun27 175:03 /usr/bin/gnome-shell

$ ps aux | grep bin/gnome-shell | head -1
jack 9891 2.5 22.2 2484628 686348 ? Sl Jun25 396:10 /usr/bin/gnome-shell

I got up to 1.4GB before restarting.
Comment 28 Adam Williamson 2011-07-21 11:45:58 EDT
The developers need logs of whatever's causing the leak. For those who have the problem, please try this, which I was asked to do:

valgrind --leak-check=full --time-stamp=yes --log-file=~/gnome-shell_valgrind.log gnome-shell --replace

you can then 'tail -f ~/gnome-shell_valgrind.log' in another console to watch the log as you use Shell. Ignore all the stuff right at startup, but keep an eye on any messages that show up as you use the system normally (note Shell will be very slow when run through valgrind). Use the Shell as long as you can bear it, then kill the valgrind, re-run shell normally, and post the log here. thanks!
Comment 29 Jack Waterworth 2011-07-21 21:32:52 EDT
Looks like valgrind does not like the ~ shortcut for $HOME.

$ valgrind --leak-check=full --time-stamp=yes --log-file=~/gnome-shell_valgrind.log gnome-shell --replace
valgrind: --log-file: filename begins with '~'
valgrind: You probably expected the shell to expand the '~', but it
valgrind: didn't.  The rules for '~'-expansion vary from shell to shell.
valgrind: You might have more luck using $HOME instead.
valgrind: Bad option: --log-file=~/gnome-shell_valgrind.log

I used the following instead:
$ valgrind --leak-check=full --time-stamp=yes --log-file=$HOME/gnome-shell_valgrind.log gnome-shell --replace
Comment 30 Zdenek Kabelac 2011-07-22 15:25:15 EDT
Created attachment 514776 [details]
Valgrind trace

Ok - as I've opened this bug - here is longer valgrind trace (50MB) - it shows couple bugs which should be rather fixed. But as I'm using rawhide - I do not experience such massive leaks as in the time of opening this BZ. So except I still thing consuming 200MB or RAM for fancy window manager is a little bit too much - it doesn't seem to grow out-of-bounds.

Anyway - trace is showing some 'possible lost' memory areas - after about couple minutes of work and another gnome-shell replacement - so as I do not know about internal details - valgrind might be wrong here.

I think primary focus should be now on the errors from the log beginning - when some code is reading uninitialized random data.

Obviously replacement lead to coredump because of usage of freed memory - so another thing to fix.

Is it enough to keep it in this BZ and developers will handle to workout bugs from the trace themselves - or should I start to generate BZ per error ?

(and sorry some packages are without debuginfo - if it's important I'll add more of them)
Comment 31 Jack Waterworth 2011-07-23 12:38:36 EDT
Created attachment 514875 [details]
gnome-shell valgrind output

I ran valgrind for 24-hours against gnome-shell with about 4-5 hours of my regular activity. Hopefully this can give us some more information. 

I have done a fair amount of customization and I hope my extensions do not skew the data.

(bugzilla would not allow me to add large file. hosting on my people page [35mb])
Comment 32 Dave P 2011-07-27 12:58:49 EDT
running a number of processes sequentially, all java.
After ~ 20 iterations Java blows up


# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f113a28674b, pid=8280, tid=139711944423168
#
# JRE version: 6.0_26-b03
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x76074b]  PSPromotionManager::copy_to_survivor_space(oopDesc*)+0x5b
#
# An error report file with more information is saved as:
# /sgml/dbpubs/penguin/hs_err_pid8280.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
/home/dpawson/bin/sax: line 5:  8280 Aborted                 (core dumped) java -cp /myjava/saxon655.jar:/myjava/xercesImpl.jar:/myjava/resolver.jar:/sgml/docbook/docbook-xsl-ns/extensions/saxon65.jar:/sgml -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl -Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.XIncludeParserConfiguration com.icl.saxon.StyleSheet -o $3 $1 $2 "saxon.extensions=1" $4 $5 $6

log file available if needed... Rather a large dump.
I suspect it may be associated with this bug,
though killall gnome-shell seems not to clear the bug?

DaveP
Comment 33 Peter Robinson 2011-08-17 17:43:18 EDT
Seems to be improved of late, could it have been this bug? https://lwn.net/Articles/455331/
Comment 34 Fedora Update System 2013-01-07 07:56:04 EST
python-urlgrabber-3.9.1-18.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/python-urlgrabber-3.9.1-18.fc17
Comment 35 Fedora Update System 2013-01-07 08:16:45 EST
python-urlgrabber-3.9.1-24.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/python-urlgrabber-3.9.1-24.fc18
Comment 36 Fedora End Of Life 2013-04-03 16:29:19 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 37 Mark Harfouche 2013-06-25 10:59:19 EDT
Not to beat a dead horse, but this seems to be happening to me.

Gnome shell's memory footprint grew uncontrollably and brought my system to a crawl. When I did an Alt+F2 r, things went back to normal.

I'll try and disable my extensions, but I just wanted to know if this was happening to anyone else.
Comment 38 Kevin Johnson 2013-10-17 07:05:25 EDT
I can readily reproduce this with Fedora 19 and gnome-shell-3.8.4-2.fc19.x86_64

I log into my desktop.  I launch a terminal with top to watch RES memory of gnome-shell (shift-M to sort by memory) and hit the super key many times in a row.  Each time I hit the super key, RES goes up.  I can do this until the system slows because of swapping and gnome-shell is over 3G of RES.   I did a pmap on the process before and after all of the biggest are not increases,  but new anonymous memory.   I can't figure out how to attach the pmaps to this bug - i must not have permission.
Comment 39 Kevin Johnson 2013-10-17 07:06:23 EDT
Here is the diff in my pmaps at least
----------------------------------------

[kevinj@rtnlr7b ~]$ 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 40 Mark Harfouche 2013-10-17 12:20:04 EDT
(In reply to Fedora End Of Life from comment #36)
> This bug appears to have been reported against 'rawhide' during the Fedora
> 19 development cycle.
> Changing version to '19'.
> 
> (As we did not run this process for some time, it could affect also
> pre-Fedora 19 development
> cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19
> End Of Life. Thank you.)
> 
> More information and reason for this action is here:
> https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Did you check that this was not happening in Fedora 20 anymore? 

We aren't getting much feedback from anyone on the status of this bug.

If Fedora is supposed to support 2 releases at a time, why is a memory leak not being addressed in F19. It still has close to 8 months of support.
Comment 41 Adam Williamson 2013-10-17 14:19:53 EDT
Mark: that's an automated comment; no-one 'checked' anything manually. And the comment doesn't mean the bug isn't being addressed, it was just a bot moving it to the most likely appropriate release.
Comment 42 Christian Stadelmann 2014-01-27 05:58:37 EST
I can confirm this bug for F20 with latest updates installed. This should make gnome-shell crash on any system when running long enough.
Comment 43 Mark Harfouche 2014-01-27 10:07:08 EST
Christian, just to help out any developers looking to squash this bug, what extensions do you have enabled?
Comment 44 Zdenek Kabelac 2014-09-02 07:38:52 EDT
Since I'm no longer using Gnome (being happy user of far more stable and usable xfce) - I cannot retest whether this bug is fixed - switching back to assigned...
Comment 45 Chad Rodrigue 2014-09-29 13:43:38 EDT
This is still not fixed.  

@Mark Harfouche, I see the problem with no extensions whatsoever.  

I wish I could change the defect to be "Fedora 21".
Comment 46 Adam Williamson 2014-09-29 14:41:15 EDT
I'd rather close it. The problem with bugs like this is that anyone who sees growing use of memory in GNOME tends to tag on, when we have no reliable indication that all the people are actually seeing the same bug, or that it's the same bug as the one the initial reporter saw or the same bug that any one person's detailed debugging relates to. At this point, any developer who sees this bug is going to see a dozen different people running very different versions of different packages who all, basically, saw 'memory use increasing', and at that point they're going to give up and move on, because there just isn't anything concrete you can *do* with that information.

I'm going to ask that anyone seeing gradually increasing memory use in GNOME with a recent Fedora release please file a bug of their own, with *at the minimum* a very detailed description of the GNOME environment you are using and *specific* and reproducible activities that reliably cause the memory usage to increase in a way that seems incorrect. Please do not 'tag on' to someone else's bug unless your circumstances exactly match the original reporter's, but file a new bug.

It may be better to file these bugs at upstream GNOME Bugzilla than downstream in Fedora's Bugzilla, as these are almost certainly not issues in Fedora's GNOME packaging, but in GNOME itself.

Ideally, the reports should include valgrind and/or massif logs, as this is the data the devs really need to identify what is causing the memory usage. See http://live.gnome.org/Valgrind and https://developer.gnome.org/optimization-guide/stable/massif.html.en . If you have trouble with this, you may be able to get help in #fedora-qa on Freenode or #fedora-desktop on GNOME IRC.

Please understand this isn't me sweeping the bug under the carpet, but the opposite: an attempt to explain how you may actually be able to get the bugs you're hitting fixed. A report like this just is not, realistically, going to result in the problem being fixed, because it is too diffuse and lacking in any kind of useful detail for a developer to use in actually finding what's going wrong and fix it.

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