Bug 1004048

Summary:	Memory leak in virt-manager
Product:	[Community] Virtualization Tools	Reporter:	devsk <funtoos>
Component:	virt-manager	Assignee:	Cole Robinson <crobinso>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	acathrow, berrange, crobinso, gscrivan
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-07-21 12:04:21 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:

Description devsk 2013-09-03 19:10:41 UTC

Description of problem:
Using the latest stable release (0.10.0) of virt-manager, built using Gentoo. As seen from 'top', the application keeps on adding about 8KB per second to its RSS eventually running the system out of memory after 2 days of uptime.

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


How reproducible:
Every time.

Steps to Reproduce:
1. Run the app.
2. Connect to couple of server using qemu+ssh.
3. Wait for few hours and see RSS of virt-manager swell, leading to eventual crash of the system.

Actual results:
Virt-manager kills the system.

Expected results:
Virt-manager keeps running for 24x7, 365days a week.

Additional info:

Comment 1 devsk 2013-09-03 19:11:24 UTC

That's not 8KB per second. That's 8KB per 3 seconds. Sorry.

Comment 2 Cole Robinson 2013-09-04 13:58:56 UTC

There's some more info in this Fedora bug:

https://bugzilla.redhat.com/show_bug.cgi?id=972371

The root issue is in pygobject but I haven't narrowed it down to file a bug yet. Upstream virt-manager has some workarounds that entirely avoid the leak if you hide performance graphs in the main manager window, but that's the best we can do until pygobject is fixed. Commits are referenced in that bug.

Comment 3 Daniel Berrangé 2013-09-26 10:08:10 UTC

I used this systemtap script to look at the issue

http://blog.verbum.org/2011/03/19/analyzing-memory-use-with-systemtap/

Five second usage
g_slice: 149200
g_malloc: 4095
GObject GdkPixbuf: 0
GObject PangoLayout: 0


Five second usage
g_slice: 147320
g_malloc: 4039
GObject GdkPixbuf: 0
GObject PangoLayout: 0


Five second usage
g_slice: 160576
g_malloc: 4095
GObject GdkPixbuf: 0
GObject PangoLayout: 0

That's 150kb leaked every 5 seconds, with one connection open with 4 inactive Vms.

If i disconnect from active connections, then only 32 bytes are leaked

Five second usage
g_slice: 32
g_malloc: 0


Five second usage
g_slice: 32
g_malloc: 0


Five second usage
g_slice: 32
g_malloc: 0


Unfortunately I'm unable to obtain userspace stack traces for these g_slice allocs

Comment 4 Cole Robinson 2013-10-03 22:36:42 UTC

I came up with a minimal reproducer and filed a pygobject bug:

https://bugzilla.gnome.org/show_bug.cgi?id=709397

Upstream virt-manager has bits to reduce the impact of the leak, and if you turn off all graphs in the UI it reduces it almost to nothing. So that's about the best we can do for now.

Comment 5 devsk 2014-07-19 19:38:50 UTC

I have pygobject 3.12.2 and virt-manager-0.10.0-r2 using Gentoo portage, both of which are supposed to have upstream fixes for the leak. But the issue with virt-manager is very much there. The rate may be even faster than before about 32KB/sec.

Is anyone testing this thing at all? I mean I just need to open virt-manager, connect to a host using qemu/ssh and just open the console of the one of the VMs. 'top' shows the leak right away. No fancy graphics or anything. Just regular console of the VM.

Comment 6 Cole Robinson 2014-07-21 12:04:21 UTC

Those packages are not the latest upstream release, so you need to file a bug with your distro. On Fedora the memory leak has been fixed for a long time