Re: [libvirt] Found mem leak in libvirtd, need help to debug

>> >> I still think these are libgfapi leaks; All the definitely lost bytes >> come from the library. >> >> ==6532== 3,064 (96 direct, 2,968 indirect) bytes in 1 blocks are >> definitely lost in loss record 1,106 of 1,142 >> ==6532== at 0x4C2C0D0: calloc (vg_replace_malloc.c:711) >> ==6532== by 0x10701279: __gf_calloc (mem-pool.c:117) >> ==6532== by 0x106CC541: xlator_dynload (xlator.c:259) >> ==6532== by 0xFC4E947: create_master (glfs.c:202) >> ==6532== by 0xFC4E947: glfs_init_common (glfs.c:863) >> ==6532== by 0xFC4EB50: glfs_init@(a)GFAPI_3.4.0 (glfs.c:916) >> ==6532== by 0xF7E4A33: virStorageFileBackendGlusterInit >> (storage_backend_gluster.c:625) >> ==6532== by 0xF7D56DE: virStorageFileInitAs (storage_driver.c:2788) >> ==6532== by 0xF7D5E39: virStorageFileGetMetadataRecurse >> (storage_driver.c:3048) >> ==6532== by 0xF7D6295: virStorageFileGetMetadata >> (storage_driver.c:3171) >> ==6532== by 0x1126A2B0: qemuDomainDetermineDiskChain >> (qemu_domain.c:3179) >> ==6532== by 0x11269AE6: qemuDomainCheckDiskPresence >> (qemu_domain.c:2998) >> ==6532== by 0x11292055: qemuProcessLaunch (qemu_process.c:4708) >> >> Care to reporting it to them? > > Of course - i will. > > But, are You sure there is no need to call glfs_fini() after qemu > process is launched? Are all of those resources still needed in libvirt? > > I understand, that libvirt needs to check presence / other-things of > storage, but after qemu is launched? We call glfs_fini(). And that's the problem. It does not free everything that glfs_init() allocated. Hence the leaks. Actually every time we call glfs_init() we print a debug message from virStorageFileBackendGlusterInit() which wraps it. And then another debug message from virStorageFileBackendGlusterDeinit() when we call glfs_fini(). So if you set up debug logs, you can check whether our init and finish calls match.