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

And same goes for panning with xrandr.

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 ()

Just got the same issue after playing OpenArena for a little bit and then exiting from it.

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.

Also happens when (dis)connecting monitors.

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.

triggering GC via alt+f2 -> lg -> memory solves this problem but the memory is not going down automatically.

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).

whats the needed info here ? there's no question in comment 10

(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.

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.

I've been discussing the possibility of scheduling a full gc after background changes with Florian. Florian, do you have a patch / test build ?

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.

*** Bug 1067456 has been marked as a duplicate of this bug. ***

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.

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.

*** Bug 1059343 has been marked as a duplicate of this bug. ***

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.