On Tue, Mar 10, 2015 at 01:56:11PM +0800, Chen Fan wrote: > in virDomainFSInfoFree(), don't free the virDomainFSInfo data. > > ==10670== 80 bytes in 2 blocks are definitely lost in loss record 576 of 793 > ==10670== at 0x4A06BC3: calloc (vg_replace_malloc.c:618) > ==10670== by 0x509DEBD: virAlloc (viralloc.c:144) > ==10670== by 0x19FBD558: qemuAgentGetFSInfo (qemu_agent.c:1837) > ==10670== by 0x1A03CF91: qemuDomainGetFSInfo (qemu_driver.c:19238) > > Signed-off-by: Chen Fan <chen.fan.fnst@xxxxxxxxxxxxxx> > --- > src/libvirt-domain.c | 2 ++ > 1 file changed, 2 insertions(+) This does fix the memory leak and makes the function behave like it's documented in virDomainGetFSInfo and virDomainFSInfoFree: http://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetFSInfo http://libvirt.org/html/libvirt-libvirt-domain.html#virDomainFSInfoFree But it changes the public API - if there are applications that already work around this function by freeing the info, this change would introduce a double free. I would NACK this if the documentation for both APIs didn't say that's how this function should behave. I'd like to hear a second opinion. Jan > > diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c > index 04545fd..7f8a7ce 100644 > --- a/src/libvirt-domain.c > +++ b/src/libvirt-domain.c > @@ -11337,4 +11337,6 @@ virDomainFSInfoFree(virDomainFSInfoPtr info) > for (i = 0; i < info->ndevAlias; i++) > VIR_FREE(info->devAlias[i]); > VIR_FREE(info->devAlias); > + > + VIR_FREE(info); > } > -- > 1.9.3 > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list