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 737630 - Memory 'leak' with repeated overview open / close: stock Fedora 21 Alpha, KVM, no extensions, no other actions
Memory 'leak' with repeated overview open / close: stock Fedora 21 Alpha, KVM...
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: overview
3.14.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2014-09-29 23:34 UTC by Adam Williamson
Modified: 2021-07-05 14:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
valgrind dump of the behaviour (177.07 KB, application/x-xz)
2014-09-29 23:34 UTC, Adam Williamson
Details
new xzdump (with Fedora 21 Final, GNOME 3.14.2) (144.24 KB, application/x-xz)
2014-12-09 17:37 UTC, Adam Williamson
Details

Description Adam Williamson 2014-09-29 23:34:29 UTC
Created attachment 287407 [details]
valgrind dump of the behaviour

Trying to practice what I preach about memory leak bugs, here's a new one for a specific case I can trigger reliably in a clean install.

Do a Fedora 21 Alpha Workstation install, create a user, and log in. Close the 'first time' yelp window. Now repeatedly open and close the Overview, while monitoring memory use.

The usage of the shell process grows persistently with each open and close. Some kind of garbage collection does occur, as every so often you'll see the usage decline, but it doesn't seem to be perfect. If I have a terminal with htop open and keep hammering Start, the pattern I see is that the usage grows for some time, then suddenly drops - but not back to its original level - then grows again, then drops again - but to a level still higher than the previous level - and so on. The overall trend is that usage increases consistently.

So far I've driven it from 300MB on startup to 349MB, where it seems to hold steady so long as I don't do anything. I believe if I keep hammering Start, it'll keep growing (then falling back, but never all the way).

I'm attaching a valgrind log of reproducing the bug (in a KVM running on a Fedora 21 host). I did several separate sessions of spamming the 'start' key, pausing for a while between sessions. htop indicating the memory use of Shell (or, valgrind, in the test) growing gradually, and never fully falling back.

This is with gnome-shell 3.14.0-2.fc21.
Comment 1 drago01 2014-10-01 11:01:28 UTC
Can you reproduce with this patch https://git.gnome.org/browse/mutter/commit/?id=b7355716885b8098107db16f633e230cd67f53bf applied?
Comment 2 Jean-François Fortin Tam 2014-12-05 02:58:57 UTC
Adam, ping?
Comment 3 Adam Williamson 2014-12-05 03:05:34 UTC
oh, god, sorry, got overtaken by events. that's not on 3.14, is it? i'll try and do a rebuild+test but i'm wiped out right now from f21 validation, I'll keep this tab lying around to remind me to do it tomorrow.
Comment 4 Adam Williamson 2014-12-09 17:07:12 UTC
oh, it looks like it is on 3.14.2, attempting to apply it to the package build shows 'reversed (or previously applied) patch detected'.

Unfortunately, symptom is still visible, I can drive the memory usage up by hammering on Start just the same - again it seems to get garbage collected to some degree, but not fully. I eyeballed the 3.14.2 source and this change is definitely in there.

I'll get new valgrind output shortly.
Comment 5 Adam Williamson 2014-12-09 17:37:30 UTC
Created attachment 292400 [details]
new xzdump (with Fedora 21 Final, GNOME 3.14.2)
Comment 6 Adam Williamson 2014-12-09 18:55:15 UTC
drago01 asked on IRC, so repeating here - the above is in a VM (qxl/SPICE/libvirt/virt-manager). I can reproduce to an extent on a laptop, but it seems less clear. In the VM the cycle of increased consumption, GC not cleaning fully, then more consumption beyond the level of the last GC seems to continue, at least I got it to 250+MB. On an Intel laptop I can drive it up to ~210MB with manual hammering or an xdotool loop, but it seems to be hard to get it past that. With the xdotool loop it just kind of sticks there. With manual hammering it seems like gc kicks in and drops the usage back to ~180MB, then I can hammer it back to 210MB, then it drops back to 180MB, and so on. There might still be a very slight upward trend, but it doesn't seem as clear as the VM case.
Comment 7 GNOME Infrastructure Team 2021-07-05 14:16:41 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.