Bug 1027192 - Extensive memory usage after changing RandR configuration - gdm memory leak
Extensive memory usage after changing RandR configuration - gdm memory leak
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-shell (Show other bugs)
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Florian Müllner
Desktop QE
: 1059343 1067456 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2013-11-06 06:07 EST by Michal Domonkos
Modified: 2015-01-06 09:05 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-06-13 06:20:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg.0.log (112.56 KB, text/plain)
2013-11-06 06:07 EST, Michal Domonkos
no flags Details

  None (edit)
Description Michal Domonkos 2013-11-06 06:07:02 EST
Created attachment 820290 [details]

Description of problem:
There's a massive slowdown in the overall desktop rendering performance after changing the screen resolution from the native one to a lower one and back.  It can be noticed when switching between the Activities Overview and the desktop back and forth.  Especially the zoom-out animation when entering the Overview becomes very jerky and I get only about 2 or 3 frames instead of a smooth transition.  This becomes worse after several Overview -> desktop -> Overview cycles until the desktop eventually freezes completely.

I didn't observe any errors in the logs.

The issue is not GPU specific; affects Intel, NVIDIA and AMD, so I assume the bug is somewhere between the Xorg and gnome-shell.  Please reassign to the proper component if needed.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open a bunch of windows 
2. Assuming you're running on the native resolution, lower it and revert back to the native one right away
3. Go to the Activities Overview and back to the desktop and repeat

Actual results:
After a few cycles the animations become jerky and eventually your desktop locks up.

Expected results:
Performance shouldn't be affected by changing the display resolution.
Comment 1 Michal Domonkos 2013-11-11 12:23:44 EST
Also happens after setting orientation of the screen with xrandr.  However, after the freeze occurred I performed "telinit 3" in a VT and got the following messages:

[ 2308.858653] nouveau E[  PGRAPH][0000:08:00.0] TRAP DISPATCH_QUERY
[ 2308.859639] nouveau E[  PGRAPH][0000:08:00.0] no stuck command?
[ 2308.859639] nouveau E[     PFB][0000:08:00.0] trapped write at 0x0020276000 on channel 0x0001fab8 [Xorg[4829]] PGRAPH/DISPATCH/QUERY reason: PAGE_NOT_PRESENT
Comment 2 Michal Domonkos 2013-11-11 12:42:21 EST
And same goes for panning with xrandr.
Comment 3 Michal Domonkos 2013-11-11 13:30:51 EST
This is a backtrace of an Xorg process at the time it's hung up:

#0  0x000000374d8ed8d3 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:81
#1  0x000000000046711c in WaitForSomething (pClientsReady=pClientsReady@entry=0x2aa5ba0) at WaitFor.c:221
#2  0x0000000000436feb in Dispatch () at dispatch.c:362
#3  0x000000000043b10a in dix_main (argc=12, argv=0x7fff2aea5768, envp=<optimized out>) at main.c:294
#4  0x000000374d821af5 in __libc_start_main (main=0x426620 <main>, argc=12, ubp_av=0x7fff2aea5768, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff2aea5758)
    at libc-start.c:274
#5  0x0000000000426651 in _start ()
Comment 4 Michal Domonkos 2013-11-11 13:53:02 EST
Just got the same issue after playing OpenArena for a little bit and then exiting from it.
Comment 5 Michal Domonkos 2013-11-19 13:20:32 EST
OK, as it turns out the performance degradation (and the freeze that might follow) is probably caused by a memory leak in gnome-shell.  After a resolution change, when I trigger the Overview a few times the gnome-shell's memory consumption will start to grow rapidly, resulting in above 60% of total RAM.  Since the machine I'm testing on is only equipped with 2 gigs of RAM it will eventually end up swapping, slowing down the whole system.
Comment 6 Michal Domonkos 2013-11-19 13:42:20 EST
Also happens when (dis)connecting monitors.
Comment 7 Michal Domonkos 2014-01-10 07:21:10 EST
Another way to trigger this bug on a laptop with an external monitor attached to it:

1. Perform a clean install
2. Log in your gnome account
3. Session starts with the laptop screen being the primary by default and the external monitor being the secondary display, so swap them to make the external monitor primary with e.g. the Super-P key combo

After this happens, there's a simple way to see the memory leak:
1. Launch "top -o %MEM"
2. Go to the Activities Overview and back to the desktop
3. Check the gnome-shell memory usage in top
4. Repeat steps 2-3 a few times

You'll notice in step 3 each time that the memory usage has increased and never decreases again.
Comment 10 Vladimir Benes 2014-03-13 06:48:02 EDT
triggering GC via alt+f2 -> lg -> memory solves this problem but the memory is not going down automatically.
Comment 11 Michal Domonkos 2014-03-13 07:24:10 EDT
When the freeze occurs it's sufficient for me to kill gnome-shell to force it to restart (without actually losing the current gnome session).
Comment 12 Matthias Clasen 2014-03-13 08:02:55 EDT
whats the needed info here ? there's no question in comment 10
Comment 13 Debarshi Ray 2014-03-13 08:57:29 EDT
(In reply to Vladimir Benes from comment #10)
> triggering GC via alt+f2 -> lg -> memory solves this problem but the memory
> is not going down automatically.

That sounds like the fundamental problem of all gjs code where the garbage collector does not kick in soon enough because it does not track memory allocated by GObject/C code.

If you have a JS object that contains big a GObject/C object (eg., a pixbuf), then the garbage collector does not know about the pixbuf. When the last reference to the JS object is dropped the GC does not account for the memory held by the GObject/C object, only the little bit held by the JS wrapper around it. This delays the garbage collection run.

Not sure if this such a big problem, unless we are still seeing significant user visible performance degradation.
Comment 14 Vladimir Benes 2014-03-13 09:01:39 EDT
I restarted g-s some hours ago:

it ate: 100 MBs
after several resolution changes and some more usage (3 hours):
it eats 500MB and even GC trigger cannot push it down to those 100MBs so it definitely leaks somewhere and that mem cannot be freed by gc either.
Comment 15 Matthias Clasen 2014-03-17 10:00:24 EDT
I've been discussing the possibility of scheduling a full gc after background changes with Florian. Florian, do you have a patch / test build ?
Comment 16 Florian Müllner 2014-03-19 12:46:20 EDT
I've just pushed gnome-shell-3.8.4-31.el7 which contains the gc patch mentioned by Matthias, and some improvements to the handling of animated backgrounds which leaked on resolution changes.
Comment 17 Matthias Clasen 2014-03-19 13:55:28 EDT
*** Bug 1067456 has been marked as a duplicate of this bug. ***
Comment 18 Vladimir Benes 2014-03-21 08:04:17 EDT
I'm quite sure this is working well. There are other issues in gnome shell but either resolution change or background don't leak memory.
Comment 19 Michal Domonkos 2014-03-27 07:57:18 EDT
Just to confirm Vlad's comment, I too don't see the originally reported issues triggered by a resolution/multihead change, so this has really been fixed.
Comment 20 Florian Müllner 2014-04-03 11:43:14 EDT
*** Bug 1059343 has been marked as a duplicate of this bug. ***
Comment 21 Ludek Smid 2014-06-13 06:20:00 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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