RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1079940 - GS should free memory allocated for application after it exists
Summary: GS should free memory allocated for application after it exists
Keywords:
Status: CLOSED DUPLICATE of bug 1546302
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-shell
Version: 7.0
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: rc
: 7.0
Assignee: Florian Müllner
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1649362 1656436
TreeView+ depends on / blocked
 
Reported: 2014-03-24 11:02 UTC by Vladimir Benes
Modified: 2019-09-23 19:12 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-29 16:13:45 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Vladimir Benes 2014-03-24 11:02:49 UTC 
I was verifying some background and resolution changes memory leaks and run into this: I'm using alt+f2 + lg + GC to free everything after every step

 * after g-s start I can see 110 MB used
 * after some time of using overview with several apps started mem usage
   goes to > 220 MB
     o after first several overview to nautilus cycles mem usage
       stabilized somewhere around 130MB
 * after some background and resolution changes memory stays in these
   boarders. (so I assume these resolution/background issues are fixed)
 * after starting LO writer G-S ate another 30MB
     o the same happened with every other LO apps (draw, calc, impress)
       so now > 350MB
     o next starts are not causing more memory eaten
 * after some more work I am up to 381MB
 * after opening 40 terminals and one with a bunch of tabs and closing
   them at once (except the active one with top running) from window
   list and I am up to 413MB
 * after doing the same again I'm up to 437MB
 * just opening a bunch of empty tabs in chrome brings me up to 445MB
 * running alt+f2 + r brings me to back to 109MB
 * after starting libreoffice writer I am at 158 MB
 * etc

Shouldn't that memory that was allocated for each application be freed after application exits?
Comment 3 Chad Rodrigue 2014-10-15 17:06:11 UTC 
Can confirm on Fedora 21 (Gnome-Shell 3.14)
Comment 6 Brendan Shephard 2018-03-22 09:37:30 UTC 
Guys, looks like what you're describing here could be related to this: https://gitlab.gnome.org/GNOME/gnome-shell/issues/64
Comment 7 Vitezslav Humpa 2018-04-16 09:45:05 UTC 
We have recently done and run a gnome-shell/gnome longetivity test that ran for 24 hours on fresh RHEL-7.5 And we indeed are seeing the issue that is heavily discussed on https://gitlab.gnome.org/GNOME/gnome-shell/issues/64. What the test does it runs apps in sequence via the Alt-F2 and then closes them using he App menu -> quit (thus is draws the app menu every time).

gnome-shell process grows from early 1.2 GB to final 4.8 GB over this 24h period. Screenshot from kibana with the process monitor data: https://screenshots.firefox.com/Zc95rC6eaG1XwDaD/str-ha-prod-2.rhev-ci-vms.eng.rdu2.redhat.com

RH internal users can access the reports here https://url.corp.redhat.com/b027f7d and here https://url.corp.redhat.com/6c27a14 (kibana/kibana).

The system used is a openstack VM instance and the system with this session is kept running, so feel free to ping me for access.

version: gnome-shell-3.26.2-5.el7.x86_64 (7.5 gold)
I believe that if the upstream hunt for these leaks comes to a resolution, that might be a candidate for backporting to 7.5.
Comment 8 afox@redhat.com 2018-11-14 17:23:09 UTC 
It now appears that this issue has been resolved upstream. 

Links to the issues are:

https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/

There is a useful summary of the issue by a developer (Philip Chimento) at:
https://gitlab.gnome.org/GNOME/gnome-shell/issues/64#note_296648

Georges Stavracas explains the "Tardy Sweep" problem in his blog post.
https://feaneron.com/2018/04/20/the-infamous-gnome-shell-memory-leak/

This is the merge request with Georges Stavracas fix for milestone "GNOME 3.28 bugfixes"
https://gitlab.gnome.org/GNOME/gjs/merge_requests/114

I would ask that we backport this to both 7.5 and 7.6, as I have TAM customers who have large numbers of RHEL workstations users who see this problem daily.
Comment 9 Tomas Pelka 2019-01-16 16:55:20 UTC 
Probably dup of https://bugzilla.redhat.com/show_bug.cgi?id=1546302
Note You need to log in before you can comment on or make changes to this bug.