On Tue, Jul 24, 2007 at 03:41:32AM +0100, Daniel P. Berrange wrote:
On Tue, Jul 24, 2007 at 02:38:40AM +0100, Daniel P. Berrange wrote:
> In looking at a problem with domain object cleanup in virt-manager I came
> across a problem in the remote driver, well the internal driver API itself
> actually. Specifically the implmenetation of virDomainFree() never calls
> into the driver API - it simply uses virFreeDomain() release the memory
> associated with the virDomainPtr object.
>
> Couple this with the remote driver though, and virDomainPtr objects in the
> remote daemon never get released, because the virDomainFree call is never
> propagated over the wire to the server.
>
> Its quite easy to see this in practice. Simply add a printf to the impl
> of virDomainLookupByName which prints out the ref count. Then run either
> virsh or virt-manager for a while
>
> Get info QEMUGuest1 69 c7a5fdbd-edaf-9455-926a-d65c16db1809
> Get info QEMUGuest1 70 c7a5fdbd-edaf-9455-926a-d65c16db1809
> Get info QEMUGuest1 71 c7a5fdbd-edaf-9455-926a-d65c16db1809
>
> We need to make virDomainFree call into the driver API, and also make sure
> that the remote driver implements it.
Actually I was wrong in this. It is not just that the virDomainLookupByName
which cause virDomainPtr objects to be allocated. Every single API call into
the daemon which uses get_nonnull_domain() causes a virDomainPtr object
to have its ref count increased. So we don't want to pass the virDomainFree
API through the driver API at all.
Instead in the server side of the remote driver, any API call which returns
a virDomainPtr *and* any call which accepts a virDomainPtr needs to have a
corresponding call to virDomainFree to reduce the ref-count in all of its
exit paths. The same goes for virNetwork objects & its calls.
I'm attaching a patch which I believe hits all the neccessary codepaths.
With a few prints in virGetDomain, I can see the refcount correctly being
incremented & decremented per API call, rather than growing without bound.
Dohh, giant memory leak ! Good catch !
A couple more may be needed and not in the list for the upcoming
DomainMigrate entry points,
+1
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/