Bug 672117
| Summary: | Mutter seems to leak a lot of memory | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Zdenek Kabelac <zkabelac> | ||||||||
| Component: | gnome-shell | Assignee: | Owen Taylor <otaylor> | ||||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 19 | CC: | acook, awilliam, benjavalero, bruce, daniell1, dave.pawson, di_p11, fedora, fid3adi, gonzo, harmus, hicham.haouari, jwaterwo, kpj104, mark.harfouche, maxamillion, mishu, mschmidt, otaylor, raj.ix86, samkraju, sangu.fedora, seg, sg266, thierry.vignaud, vedran, walters, yann | ||||||||
| Target Milestone: | --- | Keywords: | CommonBugs | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | https://fedoraproject.org/wiki/Common_F15_bugs#clutter_leaks | ||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2014-09-29 18:41:15 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 678116 | ||||||||||
| Attachments: |
|
||||||||||
Just a wild guess by watching 'top' RES memory it seems like 1MB is lost per 3 switches between Activity and desktop. 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.
> However usually mutter manages to kill itself sooner through memory corruption
> bugs.
Is there abrt bugs reported for these crashes?
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. 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. 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. 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. 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 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. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers 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. I think this is gnome-shell directly as opposed to mutter (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. :( > 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. @Owen Taylor : Can you give a comment on this ? 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. 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. (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. 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. 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. (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. 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. ("Power without the price", that is)
(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. 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.) 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. 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. 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! 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 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)
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])
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 Seems to be improved of late, could it have been this bug? https://lwn.net/Articles/455331/ 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 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 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 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. 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. 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 (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. 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. I can confirm this bug for F20 with latest updates installed. This should make gnome-shell crash on any system when running long enough. Christian, just to help out any developers looking to squash this bug, what extensions do you have enabled? 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... 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". 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. |
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: