Bug 1014265 - Gnome-Shell huge 'leaking' memory (increasing VIRT & RES) but never freeing it.
Summary: Gnome-Shell huge 'leaking' memory (increasing VIRT & RES) but never freeing it.
Keywords:
Status: CLOSED DUPLICATE of bug 977387
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-01 14:59 UTC by Chuck Lasher
Modified: 2014-11-29 04:29 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-11-29 04:29:36 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Screen capture showing Gnome-Shell having grown overnight with no interaction (73.85 KB, image/png)
2013-10-01 14:59 UTC, Chuck Lasher
no flags Details
growth after 1 minute. (74.91 KB, image/png)
2013-10-01 15:00 UTC, Chuck Lasher
no flags Details
System after becoming non-responsive. Session reset & login. (545.30 KB, image/jpeg)
2013-10-03 00:51 UTC, Chuck Lasher
no flags Details
System just prior to becoming completely non-responsive. (543.17 KB, image/jpeg)
2013-10-03 00:53 UTC, Chuck Lasher
no flags Details

Description Chuck Lasher 2013-10-01 14:59:58 UTC
Created attachment 806038 [details]
Screen capture showing Gnome-Shell having grown overnight with no interaction

Description of problem:  Gnome-shell can be observed increasing (consistently) both VIRT and RES memory with NO interaction with the desktop.  RES size will grow (sometimes wildly) until system becomes completely non-responsive (under 18-24 hours of very light use).  Only recourse is to exit (logout) of desktop session and back in (having created a fresh pid).


Version-Release number of selected component (if applicable):
gnome-shell-3.8.4-2.fc19.x86_64

How reproducible:
Start system, log in, and watch.  Please see below.  Reproducable without failure.


Steps to Reproduce:
1.  Boot system and log in
2.  Open a terminal session and start 'top'
3.  Observe VIRT and RES memory utilization of gnome-shell (process name)
4.  Normal growth can be observed with basic interactions but rate of growth
    during idle (non-interacting) state will be increased.  Gnome-shell will
    grow without interaction.  Interaction simply facilitates more rapid growth.

Actual results:
Shell continues to consume virtual (normal) and resident (not expected) memory until the system becomes non-responsive.  On this 8GB system, that point is approximately 2GB of ram.  It will NOT release the memory when it is needed.  Swap space will exceed 1GB in a few hours or as soon as gnome-shell exceeds 1GB of RES.  Top will show this clearly.

Expected results:
Gnome-shell should grow initially as pages are allocated for use.  Gnome-shell memory usage should 'stabilize' in virtual size at some point. Resident size should rise and fall based on usage and/or memory demand.

Additional info:
This bug entry is written as a free-standing bug report in an attempt to free it from the 3.6 memory leak and other downstream bug reports as this author cannot determine if it is the same major leak or not.

The 3 processes shown as running in the screen captures are linked statically.  They allocate memory at startup and perform no other malloc() calls.  It is a mathematics program with a long history of linux stability.

The screen captures were taken with gnome-screenshot (just the selected window) to minimize system impact.

Comment 1 Chuck Lasher 2013-10-01 15:00:50 UTC
Created attachment 806039 [details]
growth after 1 minute.

Comment 2 Chuck Lasher 2013-10-01 15:05:40 UTC
Will screencapture gnome-shell at 1.9g if I can get it to respond.

Comment 3 Chuck Lasher 2013-10-03 00:51:04 UTC
Created attachment 806822 [details]
System after becoming non-responsive.  Session reset & login.

This shows the system after having been up during the night with no interaction of any kind but session reset and logged back in.  Gnome-shell shows the virtual size it has accumulated overnight while sitting idle.  Please note the elevated resident size as well.  Normal, post boot, size is about 200 meg.

Comment 4 Chuck Lasher 2013-10-03 00:53:53 UTC
Created attachment 806823 [details]
System just prior to becoming completely non-responsive.

This shows the memory utilization of gnome-shell above 1g of ram.
The computer was only used for 20 minutes since the prior screenshot.  Gnome-shell accumulated it's memory without user interaction.

I hope this helps in isolating this from the other memory leak problems and makes it easier to locate.

Comment 5 Dave Fennell 2014-04-10 14:08:19 UTC
My development machine has been up for 37 days ... gnome shell is currently using over 3GB.... this top capture was with everything closed except for one terminal!


top - 15:00:04 up 37 days,  4:36,  2 users,  load average: 0.40, 1.02, 0.73
Tasks: 184 total,   2 running, 182 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.1%us,  0.8%sy,  0.3%ni, 97.4%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8084524k total,  4033428k used,  4051096k free,   232492k buffers
Swap:  4098044k total,  1706940k used,  2391104k free,  2385972k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                          
 2202 davidf    20   0 3286m 217m  13m S    2  2.8 283:09.96 gnome-shell

Comment 6 Pádraig Brady 2014-11-29 04:29:36 UTC

*** This bug has been marked as a duplicate of bug 977387 ***


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