Created attachment 744527 [details] top from the system Description of problem: gnome-shell eats a lot of mem Version-Release number of selected component (if applicable): todays f19 from testing repo gnome-shell-3.8.1-2.fc19.x86_64 Linux masox.brq.x.com 3.9.0-301.fc19.x86_64 #1 SMP Mon Apr 29 13:44:05 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux How reproducible: once on my laptop Steps to Reproduce: 1. lenovo t61 with 3G mem 2. install f19 in default configuration and see 3. top 4. Actual results: top - 15:59:54 up 22 min, 4 users, load average: 1.80, 3.16, 2.88 Tasks: 130 total, 4 running, 126 sleeping, 0 stopped, 0 zombie %Cpu(s): 23.3 us, 4.5 sy, 0.0 ni, 48.3 id, 23.5 wa, 0.0 hi, 0.3 si, 0.0 st KiB Mem: 3057964 total, 2979428 used, 78536 free, 720 buffers KiB Swap: 5193724 total, 817452 used, 4376272 free, 46372 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2375 psklenar 20 0 4504592 2.379g 1272 R 47.82 81.58 11:43.17 gnome-shell # gnome is too slow, unusable Expected results: gnome-shell eats too much of memory Additional info:
Created attachment 744529 [details] dmesg
Created attachment 744530 [details] /var/log/message /var/log/message
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
I see this too from time to time. Eventually the process is killed and restarted.
Perhaps it could be caused by this?: https://bugzilla.gnome.org/show_bug.cgi?id=711694 I'm seeing it a couple of times a day.
I've been using a locally built gnome-shell with the patch from comment #5 included since yesterday, and I haven't seen the bad behaviour noted in this bug report since then.
Proposing as a blocker as per http://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_panel_functionality
I spoke too soon. It froze again for several minutes just now and is still sluggish and taking a large amount of memory: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1699 twaugh 20 0 2862396 1.053g 39576 S 7.3 28.1 15:06.81 gnome-shell I've just seen the gnome-shell-3.10.2-2.fc20 update so I will install that and restart.
Discussed at 2013-11-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-20/f20-blocker-review.2013-11-20-17.00.log.txt . As described this might well be a blocker, but no-one at the meeting could say they were seeing the same issue - many of us are running GNOME 3, and all of us had been up for multiple days without particularly excessive memory use (my shell process is at 505MB). We'd need a more precise indication that there is a specific, known leak that will cause severe consequences for a large number of F20 users to accept this as a release blocker: Tim, it would help a lot if you can spend some time to identify more specifically exactly where the leak you're hitting is.
I'll continue to investigate.
Discussed at 2013-11-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-27/f20-blocker-review-3.2013-11-27-17.01.log.txt . Based on other testing experience, we agree there seem to be some leaks in Shell, but they don't seem to be of such extreme severity for most users that it's necessary to block the release: they can reasonably be fixed as post-release updates. Rejected as a blocker.
This only seems to happen when the "weather" extension from extensions.gnome.org is enabled. When gnome-shell stops responding to input, I can switch to another VT and run top. Switching back to the gnome-shell VT, leaving for a few seconds, then switching to the "top" VT shows that gnome-shell is using 100% cpu. Additionally, I can see that /usr/share/org.gnome.Weather.Application/org.gnome.Weather.Application is being executed.
Reported as a bug at extensions.gnome.org, and also left a comment.
Tim, did you have the URL of that extensions.gnome.org bug report? I can't find it to check on status. Thanks!
I used this link to report the bug: https://extensions.gnome.org/errors/report/613 Not sure where those reports end up. The comment I left was: twaugh I've seen gnome-shell start to use a large amount of memory and become unresponsive after enabling this extension for several hours. https://bugzilla.redhat.com/show_bug.cgi?id=960381 (about a year ago)
*** Bug 1069299 has been marked as a duplicate of this bug. ***
Reporter of Bug 1069299 says this also occurs in Fedora 21.
(In reply to Christopher Beland from comment #17) > Reporter of Bug 1069299 says this also occurs in Fedora 21. I can vouch for that. Changing Version to 21.
I've got this bug as well, it's spamming the journal non-stop. gnome-shell becomes unresponsive at times. I do not use the "weather" extension. I use: - alternate-tab - user themes - dash to dock - places status indicator I can make it go away very easily by just not using any extensions, as the problem goes away if you disabled ALL of them.
(In reply to James Eaton Gonzalez from comment #19) > I use: > > - alternate-tab > - user themes > - dash to dock > - places status indicator > > I can make it go away very easily by just not using any extensions, as the > problem goes away if you disabled ALL of them. Could you enable those extension one-by-one to figure out the culprit?
I experience this on F22 with gnome-shell-extension-weather, but not with gnome-shell-extension-openweather (currently in koji for F21 and F22, and testing for F23). The latter is much better in general so have switched to that.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.