On 18/02/16 15:06, Erik Skultety wrote: > When virt-admin is run with valgrind, this kind of output can be obtained: > > HEAP SUMMARY: > in use at exit: 134,589 bytes in 1,031 blocks > total heap usage: 2,667 allocs, 1,636 frees, 496,755 bytes allocated > > 88 bytes in 1 blocks are definitely lost in loss record 82 of 128 > at 0x4C2A9C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > by 0x52F6D1F: virAllocVar (viralloc.c:560) > by 0x5350268: virObjectNew (virobject.c:193) > by 0x53503E0: virObjectLockableNew (virobject.c:219) > by 0x4E3BBCB: virAdmConnectNew (datatypes.c:832) > by 0x4E38495: virAdmConnectOpen (libvirt-admin.c:209) > by 0x10C541: vshAdmConnect (virt-admin.c:107) > by 0x10C7B2: vshAdmReconnect (virt-admin.c:163) > by 0x10CC7C: cmdConnect (virt-admin.c:298) > by 0x110838: vshCommandRun (vsh.c:1224) > by 0x10DFD8: main (virt-admin.c:862) > > LEAK SUMMARY: > definitely lost: 88 bytes in 1 blocks > indirectly lost: 0 bytes in 0 blocks > possibly lost: 0 bytes in 0 blocks > still reachable: 134,501 bytes in 1,030 blocks > suppressed: 0 bytes in 0 blocks > > This is because virNetClientSetCloseCallback was being reinitialized > incorrectly. By resetting the callbacks in a proper way, the leak itself is > fixed, however we should still dispose of the client object properly by > issuing virObjectUnref on it. > --- > src/admin/admin_remote.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/src/admin/admin_remote.c b/src/admin/admin_remote.c > index e634fa7..e174e88 100644 > --- a/src/admin/admin_remote.c > +++ b/src/admin/admin_remote.c > @@ -180,7 +180,11 @@ remoteAdminConnectClose(virAdmConnectPtr conn) > goto done; > } > > - virNetClientSetCloseCallback(priv->client, NULL, NULL, NULL); > + virNetClientSetCloseCallback(priv->client, NULL, conn->closeCallback, > + virObjectFreeCallback); > + virNetClientClose(priv->client); > + virObjectUnref(priv->client); > + priv->client = NULL; > > rv = 0; > > NACK, actually, the unref is already preformed in remoteAdminPrivDispose, so it's not needed here. I'll fix it in v2 Erik -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list