Start virt-manager, have it connect to a qemu connection with a bunch of offline VMs, come back in a few hours and see that it's memory has climbed pretty high and is still rising. Likely some side effect of the gtk3 conversion, need to track it down.
*** Bug 882148 has been marked as a duplicate of this bug. ***
*** Bug 974287 has been marked as a duplicate of this bug. ***
Created attachment 762012 [details] Some valgrind output That is the major memory bits from a 24 hour virt-manager run under valgrind. I tried some python specific memory debugging but total objects in memory seems to be staying quite static, so it seems something below the python code is leaking. That report seems to indicate pygobject. I poked at it for a while but couldn't find anything simple.
Not sure but I feel like f19 v-m leaks pretty quickly... :-|
(In reply to Jens Petersen from comment #4) > Not sure but I feel like f19 v-m leaks pretty quickly... :-| Well, I am sure, it really does.
I am experiencing a fast memory leak using virt-manager (virt-manager-0.10.0-1.fc19.noarch) crashes my gnome session and sometime my whole machine in a few minutes. Locks up. If the box is responsive at all, I start getting out of memory messages. Steps to reproduce: start virt-manager, view a local machine. If the desktop hasn't frozen right away, close the viewer and watch it freeze. Tested on Lenovo q190 and Thinkpad X61. Both are upgraded from F-18 using the yum upgrade method. Let me know if you need additional information. The q190 is not in production and I can change anything on it. My (F-18) production viewer is stable with virt-manager running for weeks at a time. All three machines have 4G memory. Production: virt-manager-common-0.9.5-1.fc18.noarch virt-manager-0.9.5-1.fc18.noarch X61: virt-manager-0.10.0-1.fc19.noarch virt-manager-common-0.10.0-1.fc19.noarch I assume the q190 has the same packages as the X61. thanks
A few more notes: virt-manager seems to crash only when run from a root command prompt. No crashes if run as a normal user and then authenticated. My memory problems turned out to be due to deja-dup-monitor sucking up 80% of the memory; may or may not be related. Hope this helps someone.
Okay I poked at this some more and made some progress. AFAICT this still isn't virt-manager's fault really, but I pushed a couple commits that effectively stop the leak when the app isn't being used: https://git.fedorahosted.org/cgit/virt-manager.git/commit/?id=db7db9ab47dd00d746cf8a3359c1c26dbfcfa50e https://git.fedorahosted.org/cgit/virt-manager.git/commit/?id=f141c77c452d4807b516bdc40a0e86235bf5243a The trick is that you have to hide all stats graphs in the main screen from the View menu. Even without doing that, after those 2 commits the leak should be much smaller. And the graph trick only has any effect after those commits. I'll backport them to F19 soonish
I'm glad I can confirm the patches above do quite good job. I tried to apply them and virt-manager's leaked memory amount has decreased significantly, approx. to one tenth.
virt-manager-0.10.0-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/virt-manager-0.10.0-2.fc19
Package virt-manager-0.10.0-2.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing virt-manager-0.10.0-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-17656/virt-manager-0.10.0-2.fc19 then log in and leave karma (feedback).
FWIW I filed a pygobject bug: https://bugzilla.gnome.org/show_bug.cgi?id=709397
virt-manager-0.10.0-3.fc19 is already stable now.
virt-manager-0.10.0-4.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/virt-manager-0.10.0-4.fc19
virt-manager-0.10.0-4.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.