[libvirt] [PATCH] Free object after *Destroy in python bindings

Daniel P. Berrange berrange at redhat.com
Mon May 19 20:32:59 UTC 2008


On Mon, May 19, 2008 at 04:31:36PM -0400, Cole Robinson wrote:
> Daniel P. Berrange wrote:
> > On Mon, May 19, 2008 at 04:21:55PM -0400, Cole Robinson wrote:
> >> Cole Robinson wrote:
> >>> The patch below fixes an issue in the python bindings with the
> >>> vir*Destroy methods. After the object is successfully destroyed,
> >>> the payload is cleared, using 'self._o = None'. This unfortunately
> >>> screws up virt object reference counts, as the payload should be 
> >>> free'd using the appropriate vir*Free function.
> >>>
> >> Hmm, I might be wrong about this. Reading the virDomainDestroy
> >> description in libvirt.c, destroy is supposed to free the
> >> domain object if the operation is successful. The qemu driver
> >> currently does not do this. In fact, from what I gather, none
> >> of the drivers do this.
> > 
> > The docs are wrong. Destory merely hard-kills the object being managed.
> > It does not free memory associated with the object.
> > 
> >> If the virDomainDestroy comment is correct, then the original
> >> python statement is sufficient, but the drivers need to have
> >> a few virDomainFree's added.
> > 
> > I believe your patch is correct - python should not be dropping its 
> > reference to the underlying C object, afte invoking the destroy method.
> > It should be only be dropped after free is called
> 
> Worth noting that there are actually places in the code that make the
> assumption that virDomainDestroy _does_ free the domain object, such
> as the remote driver and virsh. I'll send out a patch for those as
> well.

Yes, those would be bugs / memory leaks.

Dan
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




More information about the libvir-list mailing list