[libvirt] memory leak in snapshot and since at least 1.0.2?

Hi, https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1201938 documents a memory leak we're seeing in libvirt. I've reproduced it in 1.0.2, 1.0.6, and an hourly snapshot from yesterday morning (which is built at https://launchpad.net/~serge-hallyn/+archive/libvirt-mav) To reproduce it, I define and start one domain and run virt-manager locally (just leaving it running in a vnc server). The RSS as observed by top grows over time, starting at 10M and becoming 87M in about 12 hours. When I stop the running vm, the memleak does seem to stop. Presumably having >1 domain would speed up the memleak (explaining the original bug reporter's woes) thanks, -serge

Quoting Serge Hallyn (serge.hallyn@ubuntu.com):
Hi,
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1201938 documents a memory leak we're seeing in libvirt. I've reproduced it in 1.0.2, 1.0.6, and an hourly snapshot from yesterday morning (which is built at https://launchpad.net/~serge-hallyn/+archive/libvirt-mav)
To reproduce it, I define and start one domain and run virt-manager locally (just leaving it running in a vnc server). The RSS as observed by top grows over time, starting at 10M and becoming 87M in about 12 hours.
When I stop the running vm, the memleak does seem to stop. Presumably having >1 domain would speed up the memleak (explaining the original bug reporter's woes)
No, the memory leak did not stop altogether with the VM stopped. Since sending that email RSS has gone up by about 2M.

On 07/26/2013 10:09 AM, Serge Hallyn wrote:
Quoting Serge Hallyn (serge.hallyn@ubuntu.com):
Hi,
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1201938 documents a memory leak we're seeing in libvirt. I've reproduced it in 1.0.2, 1.0.6, and an hourly snapshot from yesterday morning (which is built at https://launchpad.net/~serge-hallyn/+archive/libvirt-mav)
To reproduce it, I define and start one domain and run virt-manager locally (just leaving it running in a vnc server). The RSS as observed by top grows over time, starting at 10M and becoming 87M in about 12 hours.
When I stop the running vm, the memleak does seem to stop. Presumably having >1 domain would speed up the memleak (explaining the original bug reporter's woes)
No, the memory leak did not stop altogether with the VM stopped. Since sending that email RSS has gone up by about 2M.
We recently found a memory leak bug in netcf that impacts debian-based builds but not Fedora-based builds. Does your issue go away once you pick up that fix? https://lists.fedorahosted.org/pipermail/netcf-devel/2013-August/000844.html -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

Quoting Eric Blake (eblake@redhat.com):
On 07/26/2013 10:09 AM, Serge Hallyn wrote:
Quoting Serge Hallyn (serge.hallyn@ubuntu.com):
Hi,
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1201938 documents a memory leak we're seeing in libvirt. I've reproduced it in 1.0.2, 1.0.6, and an hourly snapshot from yesterday morning (which is built at https://launchpad.net/~serge-hallyn/+archive/libvirt-mav)
To reproduce it, I define and start one domain and run virt-manager locally (just leaving it running in a vnc server). The RSS as observed by top grows over time, starting at 10M and becoming 87M in about 12 hours.
When I stop the running vm, the memleak does seem to stop. Presumably having >1 domain would speed up the memleak (explaining the original bug reporter's woes)
No, the memory leak did not stop altogether with the VM stopped. Since sending that email RSS has gone up by about 2M.
We recently found a memory leak bug in netcf that impacts debian-based builds but not Fedora-based builds. Does your issue go away once you pick up that fix? https://lists.fedorahosted.org/pipermail/netcf-devel/2013-August/000844.html
Yup - well, the original reporter says there remains a very slow leak, but I've not reproduced that one yet. The netcf one was definately responsible for the major leak. thanks! -serge
participants (2)
-
Eric Blake
-
Serge Hallyn