Bug 1221010

Summary:	rhel6 as guest os lead to xorg process memory leak(spice+screensaver)
Product:	Red Hat Enterprise Linux 6	Reporter:	马立克 <like.ma>
Component:	xorg-x11-drv-qxl	Assignee:	Default Assignee for SPICE Bugs <rh-spice-bugs>
Status:	CLOSED ERRATA	QA Contact:	SPICE QE bug list <spice-qe-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.8	CC:	cfergeau, dblechte, fziglio, laurent.deniel, pgrunt, rbalakri, tpelka, uril
Target Milestone:	rc
Target Release:	6.8
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	xorg-x11-drv-qxl-0.1.1-19.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1398296 (view as bug list)		Environment:
Last Closed:	2016-05-10 19:49:54 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1398296

Description 马立克 2015-05-13 06:23:52 UTC

Description of problem:
In the virtualization environment such as RHEV or oVirt, use the RHEL6 as the guest os of virtual machine. The vm use spice protocol. In the RHEL6 guest os, enable the gnome-screensaver and use the classic "floating feet" as screensaver theme. Use spice client connect to the vm, and login the desktop. Then don't log out, just close the spice client. As time goes on, the memory size which xorg process used will increase continually.

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

How reproducible:
Always

Steps to Reproduce:
1.Create a vm in the RHEV or oVirt environment, use spice protocol to connect the vm
2.Use spice client connect to the vm.
3.Install RHEL6.x in the vm(it should include desktop soteware package group and start up desktop as default)
4.Log in the desktop, make sure the screensaver has been enabled and the "floating feet" has been selected as the screensaver theme
5.Use top command to check the memory usage of xorg process
6.Don't log out the desktop, just close the spice client window
7.Several hours later, use spice client connect to the vm and log in with the same user.Use top command to check the memory usage of xorg process
8.Don't log out the desktop, just close the spice client window
9.More hours later, use spice client connect to the vm and log in with the same user.Use top command to check the memory usage of xorg process

Actual results:
As time goes on, the memory usage of xorg process will increase continually

Expected results:
the memory usage of xorg process should not increase to a very big size

Additional info:
If the user log out, the xorg process will be terminated. So after log out, memory leak can not be watched.

Comment 1 马立克 2015-05-13 06:27:00 UTC

If use the VNC protocol, everything is fine, so maybe it's a bug of spice.

Comment 3 Uri Lublin 2015-05-13 07:52:14 UTC

Moving to the X qxl driver.
This is probably a duplicate of bug 1192154 which has a fix

Comment 4 Pavel Grunt 2015-05-19 08:29:05 UTC

It is happening with xorg-x11-drv-qxl-0.1.1-17.el6.x86_64

Comment 5 Christophe Fergeau 2015-05-20 13:20:08 UTC

Does not happen with spice+cirrus but happens with vnc+qxl.

Comment 6 Frediano Ziglio 2015-10-14 12:57:32 UTC

As it happened with xorg-x11-drv-qxl-0.1.1-17.el6.x86_64 (as Pavel reported on 2015-05-19) looks like bug 1192154 fix did not solve the issue.

Comment 7 Frediano Ziglio 2015-10-20 12:15:49 UTC

From valgrind, 

==32064== 504 (24 direct, 480 indirect) bytes in 1 blocks are definitely lost in loss record 305 of 385
==32064==    at 0x4A0729A: malloc (vg_replace_malloc.c:299)
==32064==    by 0x5906BF2: insert_image_info (qxl_image.c:106)
==32064==    by 0x5906BF2: qxl_image_create (qxl_image.c:251)
==32064==    by 0x5907E24: real_upload_box (qxl_surface.c:253)
==32064==    by 0x5907E24: qxl_upload_box (qxl_surface.c:283)
==32064==    by 0x5907FC2: qxl_surface_finish_access (qxl_surface.c:360)
==32064==    by 0x59219A3: uxa_check_poly_fill_rect (uxa-unaccel.c:314)
==32064==    by 0x5918378: uxa_poly_fill_rect (uxa-accel.c:868)
==32064==    by 0x52C57C: ??? (in /usr/bin/Xorg.bin)
==32064==    by 0x58B229: miPaintWindow (in /usr/bin/Xorg.bin)
==32064==    by 0x58B777: miWindowExposures (in /usr/bin/Xorg.bin)
==32064==    by 0x5A3947: miHandleValidateExposures (in /usr/bin/Xorg.bin)
==32064==    by 0x465305: ??? (in /usr/bin/Xorg.bin)
==32064==    by 0x467AE9: ConfigureWindow (in /usr/bin/Xorg.bin)
==32064== 

==32064== 4,680 (72 direct, 4,608 indirect) bytes in 3 blocks are definitely lost in loss record 355 of 385
==32064==    at 0x4A0729A: malloc (vg_replace_malloc.c:299)
==32064==    by 0x5906BF2: insert_image_info (qxl_image.c:106)
==32064==    by 0x5906BF2: qxl_image_create (qxl_image.c:251)
==32064==    by 0x5907E24: real_upload_box (qxl_surface.c:253)
==32064==    by 0x5907E24: qxl_upload_box (qxl_surface.c:283)
==32064==    by 0x5907FC2: qxl_surface_finish_access (qxl_surface.c:360)
==32064==    by 0x59219A3: uxa_check_poly_fill_rect (uxa-unaccel.c:314)
==32064==    by 0x5918378: uxa_poly_fill_rect (uxa-accel.c:868)
==32064==    by 0x52C57C: ??? (in /usr/bin/Xorg.bin)
==32064==    by 0x58B229: miPaintWindow (in /usr/bin/Xorg.bin)
==32064==    by 0x58B777: miWindowExposures (in /usr/bin/Xorg.bin)
==32064==    by 0x5A3947: miHandleValidateExposures (in /usr/bin/Xorg.bin)
==32064==    by 0x46627F: UnmapWindow (in /usr/bin/Xorg.bin)
==32064==    by 0x436FC9: ??? (in /usr/bin/Xorg.bin)
==32064== 

==32064== 16,015,872 (98,208 direct, 15,917,664 indirect) bytes in 4,092 blocks are definitely lost in loss record 385 of 385
==32064==    at 0x4A0729A: malloc (vg_replace_malloc.c:299)
==32064==    by 0x5906C5D: insert_image_info (qxl_image.c:106)
==32064==    by 0x5906C5D: qxl_image_create (qxl_image.c:251)
==32064==    by 0x5907147: qxl_surface_put_image (qxl_surface.c:798)
==32064==    by 0x59192AF: uxa_copy_n_to_n (uxa-accel.c:582)
==32064==    by 0x588A34: miCopyRegion (in /usr/bin/Xorg.bin)
==32064==    by 0x5890D9: miDoCopy (in /usr/bin/Xorg.bin)
==32064==    by 0x59187FD: uxa_copy_area (uxa-accel.c:642)
==32064==    by 0x52A467: ??? (in /usr/bin/Xorg.bin)
==32064==    by 0x435F18: ??? (in /usr/bin/Xorg.bin)
==32064==    by 0x438DD5: ??? (in /usr/bin/Xorg.bin)
==32064==    by 0x43C839: ??? (in /usr/bin/Xorg.bin)
==32064==    by 0x333A01ED5C: (below main) (in /lib64/libc-2.12.so)
==32064== 

(particularly last one)

Image cache leaks are fixed by http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/commit/?id=e4597f711d9e7586adf5fc58887bc3407869361d, see also https://bugzilla.redhat.com/show_bug.cgi?id=1248602

Comment 9 Frediano Ziglio 2016-02-02 09:19:40 UTC

Errata RHBA-2015:21906-04

Comment 10 Frediano Ziglio 2016-02-02 10:36:08 UTC

Building 

Created task: 10428399
Task info: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=10428399

Comment 14 errata-xmlrpc 2016-05-10 19:49:54 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0761.html

Comment 15 Laurent Deniel 2016-11-24 11:45:11 UTC

Why this memory leak (wrong image caching) has not been fixed in RHEL7 as well (as of RHEL7.3) ?

Comment 16 Christophe Fergeau 2016-11-24 12:10:08 UTC

Ah looks like this was missed, created https://bugzilla.redhat.com/show_bug.cgi?id=1398296